What Is Cloud Shell In Azure

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 table

This 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, Location

Get-AzResourceGroup retrieves all resource groups visible to your current session, and piping to Select-Object trims the output down to just the group name and region, which is usually all you need for a fast inventory check. For more Az PowerShell fundamentals, our Azure PowerShell tutorial is a good next stop.

Pro Tip: If you’re ever unsure which shell to reach for on a given task, our comparison of Azure PowerShell vs. Azure CLI is worth a read — the honest answer is that most administrators need fluency in both, and Cloud Shell removes the excuse of “I don’t have that tool installed” for either one.

Identity, Authentication, and Access Control

Cloud Shell doesn’t introduce a separate authentication system — it rides entirely on your existing Microsoft Entra ID sign-in. When you open Cloud Shell from the Azure portal, you’re already authenticated as whatever account you used to log into the portal, and Cloud Shell inherits that identity’s permissions for every command you run.

This is actually a meaningful security advantage over some local setups. There’s no separate az login credential cache sitting on a laptop that could be extracted if the machine is compromised, and there’s no local storage of a service principal secret for day-to-day interactive use. Your session token is scoped to the browser session and expires with it.

That said, this also means Cloud Shell is exactly as powerful — or as dangerous — as the account using it. If someone signs into Cloud Shell with an account that has Owner rights on a subscription, they can run a command like az group delete and take down an entire environment just as easily as they could from a local terminal.

This is why role-based access control (RBAC) discipline matters just as much here as anywhere else. Review our explainer on what RBAC is and consider whether the accounts your team uses for daily Cloud Shell work should have broad Contributor or Owner roles versus something more narrowly scoped.

A few practical access-control habits I recommend:

Test with a non-administrator account whenever you’re validating a new automation script in Cloud Shell, so you catch permission gaps before they surface in production.
Avoid running Cloud Shell sessions from shared or unmanaged devices, since the browser session itself is tied to whatever Entra ID session is active on that browser.
Check your assigned role before assuming access using a quick command, especially in subscriptions you don’t normally administer — our guide on how to check your role in the Azure portal covers this well.Pro Tip: I’ve caught more than one accidental “wrong subscription” mistake by running az account show at the start of every Cloud Shell session before executing anything destructive. It takes two seconds and has saved me from deleting the wrong environment’s resources at least twice.

Networking and Cloud Shell: What You Can and Can’t Reach

By default, Cloud Shell’s container runs on Microsoft-managed infrastructure outside your virtual network, which means it reaches your Azure resources over their public endpoints. For most day-to-day administrative tasks — managing resource groups, checking VM status, deploying Bicep templates — this is completely fine, since those operations go through Azure Resource Manager’s public API regardless of where you run the command from.

The complication comes when your organization has locked down resources behind private endpoints or restricted network security groups (NSGs) that block public access entirely.

If your Azure SQL Database or storage account only accepts connections from inside a specific virtual network, a default Cloud Shell session running on Microsoft’s infrastructure won’t be able to reach it — you’ll get a connection timeout or a permission-denied error that has nothing to do with your credentials and everything to do with network isolation.

For that scenario, Azure supports Cloud Shell VNet integration, which deploys the Cloud Shell container into a subnet inside your own virtual network using an isolated container instance. This requires additional setup — a dedicated subnet, an Azure Container Instance, a Relay namespace, and a storage account inside the VNet — and it’s a meaningfully more complex configuration than the default experience.

If you’re running an environment where every data resource sits behind private networking, plan for this upfront rather than being surprised by it after your team already depends on Cloud Shell daily.

Pro Tip: I’ve seen teams spend an hour debugging what looked like an authentication failure in Cloud Shell, when the real issue was that the target SQL server had public network access disabled. Always check the target resource’s network settings before assuming a Cloud Shell error is about identity or RBAC.

Common Cloud Shell Tasks and Realistic Scenarios

Cloud Shell earns its keep in a handful of recurring situations I run into constantly across client environments.

Emergency access from an unmanaged machine. If you’re on-call and the only device available is a personal laptop or a borrowed machine, Cloud Shell lets you sign in through a browser and manage resources without installing anything locally — useful for restarting a stopped VM or checking why a web app is stopped during an incident.

Quick infrastructure-as-code deployments. Cloud Shell comes with Terraform and Bicep support baked in, so you can clone a repository, run terraform apply or az deployment group create, and validate infrastructure changes without setting up a local development environment. This is genuinely useful for reviewing a colleague’s pull request quickly — clone, plan, inspect, done.

Onboarding and training environments. New team members or students working through Azure fundamentals material can start running real commands within minutes, which matters a lot for organizations running internal Azure training or preparing staff for the AZ-900 exam.

Ad hoc scripting without local environment drift. Since Cloud Shell’s tools are centrally maintained by Microsoft, you avoid the classic problem of “it worked on my machine” where one engineer has an outdated CLI version and another has a newer one with different flag behavior.

Here’s an example of a common real task — checking current subscription context and switching to a different one before running a deployment, something I do constantly when managing multiple client subscriptions from one Cloud Shell session:

az account list --output table
az account set --subscription "<subscription-name-or-id>"

The first command lists every subscription your signed-in account has access to. The second switches your active context to the specified subscription, which is critical to run correctly before any resource creation or deletion command — accidentally deploying or deleting against the wrong subscription is one of the most common and costly mistakes in multi-subscription environments.

For more on this, see how to check the current subscription in Azure PowerShell if you’re working from the PowerShell environment instead.

Pro Tip: In multi-client or multi-environment setups, I make it a habit to run az account show --output table immediately after every subscription switch, not just trust that the set command worked silently. It’s a small habit that prevents a genuinely bad day.

How to access Azure Cloud Shell

There are two ways to access the Azure Cloud Shell

With the help of Browser

You can access the Azure Cloud Shell with the help of your favorite Browser. To access the Azure Cloud Shell via browser, you can access the below URL.

https://shell.azure.com/

Via Azure Portal

The Azure Portal is another easy option to access the Azure Cloud Shell. You can follow the steps below to access the Azure Portal using the Azure Cloud Shell.

Log in to the Azure Portal (https://portal.azure.com/)
Once you have logged in to the Azure Portal, You can click on the Cloud Shell button, which is present at the top right as highlighted below.

As the next step, it will ask you to select the Bash or PowerShell option. You can choose the option based on your requirements.

Note that if you are using the Cloud Shell for the first time, it will ask you to create storage if you choose Bash or PowerShell. You can click on the Create Storage button to create the storage.

How to access Azure Cloud Shell using Azure Portal

Now, it will take a few seconds to create the storage, and then you can see It is showing that you are Requesting a cloud shell. Succeeded and connected to the terminal successfully. Now, you can enter the different commands to manage different Azure resources.

How to access Azure Cloud Shell in Azure Portal

Cost, Limits, and Governance Considerations

Cloud Shell itself doesn’t have a direct compute charge — the container time you use is included at no additional cost. The expense you do incur is the backing storage account and file share, which is billed like any other Azure Storage account based on the storage tier and capacity consumed.

For most individual or small-team use, this cost is minor, but it’s not zero, and in large organizations with many users each spinning up their own storage account, it adds up in ways that are easy to miss during a cost review.

A few governance points worth building into your setup from day one:

Consolidate storage accounts where sensible. Rather than letting every user auto-provision their own Cloud Shell storage account, consider standardizing on a small number of shared accounts per team, tagged clearly, so cost attribution stays clean. Our guide on what Azure tags are is useful if you’re setting up a tagging policy for this.
Session timeout limits idle costs. Cloud Shell automatically disconnects after around 20 minutes of inactivity, which is a built-in safeguard against runaway sessions, but it’s still worth knowing this behavior exists so users aren’t confused when a long-idle session drops.
Review Azure Advisor periodically for unused or orphaned Cloud Shell storage accounts left behind by departed employees or abandoned experiments — Azure Advisor surfaces this kind of waste well if you check it regularly.
Apply resource locks carefully. If your Cloud Shell storage account also holds other important file shares, consider a resource group lock to prevent accidental deletion during cleanup sweeps.
Pro Tip: During a subscription cleanup project last year, we found eleven separate “cloud-shell-storage” accounts across one client’s dev subscription, most abandoned by contractors who’d left months earlier. A quick Azure Policy rule requiring approval for new storage account creation would have caught this early.

Production Readiness Considerations

Storage account ownership should be deliberate, not left to the first-run wizard — create it under proper naming conventions and resource group structure before your team’s first login.
RBAC scoping matters more than the tool itself — Cloud Shell doesn’t add security, it inherits whatever access the signed-in account already has, so audit those role assignments regularly.
VNet integration adds real complexity — only invest in isolated Cloud Shell networking if your resources genuinely sit behind private endpoints; don’t add it preemptively.
Session persistence is storage-dependent — remind users that anything saved outside $HOME or the mounted file share disappears when the container recycles.
Multi-subscription hygiene prevents costly mistakes — always confirm active subscription context before running deployment or deletion commands.
Idle Cloud Shell storage accounts accumulate — periodically audit for orphaned resources tied to former employees or abandoned test setups.

Frequently Asked Questions

What is Azure Cloud Shell used for?

Azure Cloud Shell gives administrators and developers a browser-based terminal preloaded with Azure CLI, Azure PowerShell, Terraform, and other tools so they can manage Azure resources without installing anything locally. It’s especially useful for quick administrative tasks, emergency access from unmanaged devices, and onboarding new team members.

Is Azure Cloud Shell free to use?

The compute time for running Cloud Shell sessions has no separate charge, but you do pay for the backing storage account and file share that persists your home directory across sessions. That storage cost is typically small but should still be tracked as part of your overall cost management practice.

Does Cloud Shell require any local software installation?

No. Cloud Shell runs entirely in your browser and requires only that you sign in with your Microsoft Entra ID account through the Azure portal, shell.azure.com, or the Azure mobile app. All the command-line tools are preinstalled and maintained by Microsoft.

Can Cloud Shell access resources behind private endpoints?

Not by default — a standard Cloud Shell session runs on Microsoft-managed infrastructure outside your virtual network and reaches resources over public endpoints. To reach privately networked resources, you need to configure Cloud Shell VNet integration, which deploys the container into your own subnet.

What’s the difference between the Bash and PowerShell environments in Cloud Shell?

Bash is built around Azure CLI and Linux-style tooling, while PowerShell comes with the Az PowerShell module preloaded for cmdlet-based administration. Both share the same persistent home directory, so you can switch between them without losing saved scripts or files.

Which resource is required to use Azure cloud shell

Below are the resources that are needed here.

An Azure Subscription. Note that you need an Azure subscription to use Azure cloud shell. If you don’t have one, you can create an Azure free account now.
A Storage Account. If you have not yet created. You can create a storage account now.
A Resource Group. You can create a Resource Group now.

What can you use to launch the Azure cloud shell?

You can access the Azure Cloud Shell from below.

What is the use of Azure Cloud shell?

Answer: You can develop and manage Azure resources using Azure Cloud Shell.

How do I save files in Azure cloud shell?

You can press Ctrl + S keys from your keyboard to save the file.

What should you use to access Azure cloud shell

User Azure Portal and click on the Cloud Shell icon from the top.

Azure Cloud Shell removes the setup friction that keeps administrators and developers from getting straight to work, giving you an authenticated, preconfigured terminal in any browser. The convenience doesn’t replace good RBAC hygiene, storage governance, or network planning — those decisions still determine whether your Cloud Shell usage stays secure and cost-controlled as your team grows. I hope you found this article helpful.