Cloud Shell Security: AWS, Azure and Google Cloud Controls

Browser-based cloud shells give anyone with a console session an authenticated command line, persistent storage and outbound internet access, which makes a stolen console session far more dangerous and creates an exfiltration path that many organisations never review. AWS CloudShell, Azure Cloud Shell and Google Cloud Shell are convenient for administrators, but they inherit the signed-in identity's permissions, keep files in a home directory across sessions and sit outside most endpoint controls. This guide explains how each shell handles credentials, storage, networking and session limits, the risks that follow, and the controls each provider documents to restrict, isolate, log and disable the service. It is written for cloud security engineers, platform teams and identity architects. Platforms are listed alphabetically; order is not a ranking. Provider documentation was checked on 8 November 2026 and limits change, so confirm current values before relying on them.

Key takeaways

The shell is the console identity with a terminal attached. AWS documents that CloudShell uses the IAM credentials used to sign in to the console; Azure Cloud Shell authenticates automatically; Google Cloud Shell prompts the user to authorise credentials on first use of an API. Whoever holds the console session holds the shell.
Home directories persist and are a credential hiding place. AWS keeps 1 GB per Region for 120 days after last use, Azure mounts a 5 GB Azure Files share if a storage account is chosen, and Google keeps a 5 GB home directory until 120 days without access. Keys and tokens saved there outlive the session.
Outbound internet means a data path. AWS warns that internet access creates a risk of data export. All three shells can reach the internet by default, and all three offer some form of upload and download through the browser.
Each provider offers a different control set. AWS uses IAM actions such as cloudshell:PutCredentials and cloudshell:GetFileUploadUrls; Azure offers virtual network isolation and network blocking of *.console.azure.com; Google offers an Admin console Cloud Shell access setting and ephemeral mode.
Protect the session first. Phishing-resistant MFA, short console sessions, conditional access and privileged access workstations reduce the chance that an attacker ever reaches a shell.

How the three cloud shells work

All three services provide a provider-managed Linux environment per user, launched from the web console, preloaded with the provider's CLI. The differences that matter for security are summarised below, using each provider's own documentation.

Aspect	AWS CloudShell	Azure Cloud Shell	Google Cloud Shell
Credentials	Uses the IAM credentials used to sign in to the console, forwarded by cloudshell:PutCredentials	Authenticates automatically for Azure CLI and Azure PowerShell	Prompts the user to authorise access on first use of an API or tool needing credentials
Persistent storage	1 GB per Region in $HOME; kept 120 days after last session in that Region	5 GB Azure Files share in a storage account (clouddrive), or no storage account; $HOME without storage is deleted at session end	5 GB home directory, not expandable; deleted after 120 days without access
Idle timeout	20 to 30 minutes (10 minutes in AWS GovCloud (US))	20 minutes without interactive activity	VM terminates after 40 minutes of inactivity; non-interactive sessions end after 40 minutes
Maximum session	About 12 hours	Not stated in the pages checked	12 hours
Network	Outbound public internet; no inbound ports, no public IP; optional VPC environments	Microsoft-managed container by default; optional deployment into a customer virtual network using Azure Relay	Short-lived Google-managed VM not shown in your projects
Concurrency and quotas	Up to 10 shells per Region per account; monthly Regional quota	20 concurrent users per tenant	50 hours per week by default
Ephemeral option	VPC environments have no persistent storage	No storage account required option	Ephemeral mode: files lost when the session ends

Availability notes. AWS: CloudShell storage is free at 1 GB per Region; VPC environments are limited to two per IAM principal. Azure: the storage account and, for virtual network isolation, Azure Relay are billed. Google: the 50-hour weekly quota is the default, and Google Workspace for Education blocks Cloud Shell for all users by default on an age basis.

Threats and risks

Risk	How it arises	ATT&CK v20
Session hijack becomes command execution	A stolen console cookie or adversary-in-the-middle phishing gives the attacker the console, and the shell gives them the CLI with the same permissions	T1539 Steal Web Session Cookie; T1078.004 Cloud Accounts
Credentials left in the home directory	Users save access keys, service account key files, kubeconfig files or tokens in $HOME, which persists across sessions	T1552.001 Credentials In Files
Persistence through startup files	Google runs $HOME/.customize_environment as root at boot, and shell profiles such as .bashrc run in every shell; a modified file executes on the victim's next session	Treat as unauthorised change to user environment
Data export	Browser upload and download, or outbound internet from the shell to attacker storage	Exfiltration over web services
New long-lived credentials	An attacker in the shell creates access keys or service account keys for persistence	T1098.001 Additional Cloud Credentials
Token theft from the shell	Tokens available inside the environment are copied and reused elsewhere	T1528 Steal Application Access Token
Bypass of network controls	The shell runs outside corporate egress filtering and endpoint monitoring by default	Visibility gap rather than a technique

The common thread is identity. A cloud shell does not add permissions, but it removes friction: an attacker who would otherwise need to install tools or extract tokens from a browser can run the CLI directly. See the Session Hijacking and Cookie Theft Guide.

AWS CloudShell controls

Launch permissions: launching requires cloudshell:CreateEnvironment, cloudshell:CreateSession, cloudshell:GetEnvironmentStatus and cloudshell:StartEnvironment. AWS offers the AWSCloudShellFullAccess managed policy and suggests building custom policies from the CloudShellPolicy template. It notes that AdministratorAccess and PowerUserAccess style policies also allow CloudShell.
Deny entirely: a Deny on cloudshell:* blocks the service for the principals it applies to. Apply it through a service control policy in AWS Organizations to cover whole OUs; see the AWS Organizations and SCPs Guide.
Block browser file transfer: deny cloudshell:GetFileDownloadUrls and cloudshell:GetFileUploadUrls. AWS states plainly that users can still transfer files with clients such as wget, so this reduces casual transfer, not determined exfiltration.
Stop credential forwarding: deny cloudshell:PutCredentials so the console credentials are not forwarded; users must then configure credentials themselves inside the shell. Use this where shells are allowed only for low-privilege tasks.
VPC environments: run CloudShell inside your own VPC so traffic follows your routing and egress controls. AWS documents no persistent storage for VPC environments and no browser upload or download.
Logging: CloudTrail records CloudShell API calls with event source cloudshell.amazonaws.com, including createEnvironment, createSession, putCredentials, getFileUploadUrls and getFileDownloadUrls. The CLI calls made from the shell appear under each target service's events, not as CloudShell events. See the AWS CloudTrail Guide.

Azure Cloud Shell controls

Block at the network: Microsoft documents restricting access to *.console.azure.com (or *.console.azure.us in US Government) to stop connections, while noting this does not cover all entry points such as VS Code for the Web and Windows Terminal; blocking every entry point in a tenant needs a support ticket.
Virtual network isolation: deploying Cloud Shell into a customer virtual network lets administrators manage resources that have only private IP addresses, keeps the storage account free of public access, and can restrict Cloud Shell use to the virtual network. Azure Relay carries the browser connection, with one hybrid connection per administrator per session, closed when the session ends. See the Azure Virtual Network Security Guide.
Storage choice: users choose between mounting a storage account (clouddrive, persistent) and no storage account. Files in clouddrive persist and are visible in the Storage browser; with no storage account, $HOME is deleted when the session ends. Treat Cloud Shell storage accounts as sensitive and apply the controls in the Azure Storage Security Guide.
Azure Policy interaction: a policy that denies Microsoft.Storage/storageAccounts/write causes a 403 RequestDisallowedByPolicy when a first-time user tries to create Cloud Shell storage, which can be used deliberately to force the no-storage option.
Personal data reset: resetting user settings ends the session and unmounts the storage account, but Microsoft notes the Azure file share is not deleted. Include those shares in leaver and data retention processes.
Logging: activity performed with Azure CLI or PowerShell from the shell appears in the Azure Activity Log under the user's identity. See the Azure Monitor, Activity Log and Diagnostic Settings Guide.

Google Cloud Shell controls

Admin disable: in the Google Admin console, Cloud Shell settings under Google Cloud Platform let administrators turn off Cloud Shell access, or turn it off for specific users through an access group.
Ephemeral mode: starts faster and discards files created in the session, removing the persistent home directory risk for users who do not need it.
Startup script awareness: $HOME/.customize_environment runs as root when the VM boots. Review it, together with shell profiles, during incident response, because it is a natural persistence point.
Home directory lifecycle: the 5 GB home directory is deleted only after 120 days without access, and deletion is permanent. Users can reset by deleting $HOME and restarting, which provisions a new VM.
Acceptable use: Google prohibits coin mining and network scanning from Cloud Shell, and violations can lead to Cloud Shell being disabled for the account. Alerts from Google about such use on a corporate account should be treated as a possible compromise.
Logging: API calls made with gcloud from the shell appear in Cloud Audit Logs under the user's principal. See the Google Cloud Audit Logs and Log Sinks Guide.

Where identity fits

Cloud shells are an identity problem with a terminal on top. The controls that matter most sit in the identity layer.

Phishing-resistant MFA for console access: FIDO2 or passkeys stop the adversary-in-the-middle phishing that steals console sessions. See the Phishing-Resistant MFA Guide.
Conditional access and device trust: require compliant or managed devices for administrative console access; see the Conditional Access Guide and the Privileged Access Workstations Guide.
Just-in-time privilege: if console roles are elevated only for a task, the shell inherits low privilege most of the time. See the Cloud PAM and CIEM Guide.
No long-lived keys in shells: the shell already has the user's credentials, so there is no reason to store access keys or service account key files in $HOME. See the AWS Access Keys Security Guide and the Google Cloud Service Account Keys Security Guide.
Workload identities are out of scope for shells: automation should run in pipelines with workload identity federation, not in someone's cloud shell under a human identity.

Deciding policy: allow, restrict or disable

Option	When it fits	Trade-off
Disable for all users	Administration is done from managed workstations or a bastion; regulated environments	Administrators lose a convenient break-fix tool; make sure break-glass procedures do not depend on it
Allow for a named admin group only	Most organisations; platform teams need it, business users do not	Requires group maintenance and periodic review
Allow with isolation (AWS VPC environments, Azure virtual network isolation, Google ephemeral mode)	Shell use is common and egress or storage is the main concern	Extra setup and, on Azure, Relay and storage cost; slower start-up
Allow with transfer limits	Low-risk accounts, sandboxes, training	Transfer limits are bypassable; AWS notes wget still works

Small organisations often rely on cloud shells because they lack managed admin workstations; in that case keep them but enforce phishing-resistant MFA, ephemeral or no-storage options and a ban on storing keys. Large organisations should restrict shells to an admin group, route them through private networking where offered, and alert on use by anyone else.

Implementation steps

Measure current use. Query CloudTrail for eventSource cloudshell.amazonaws.com, review Azure sign-in and Activity Log data for portal-originated CLI activity, and check Google Admin settings and audit logs. List who uses shells and why.
Agree the policy per platform. Choose disable, admin-only or isolated, and document the reason and owner.
Pilot restrictions. AWS: attach the Deny policies (transfer, PutCredentials or cloudshell:*) to a pilot group before an SCP. Azure: pilot virtual network isolation with one admin team, or block *.console.azure.com from a test network segment. Google: apply the Cloud Shell access setting to a pilot group.
Roll out in rings. Expand from pilot to all non-admin users, then to admins as isolated options mature.
Clean up stored data. Ask users to remove credentials from shell home directories; for Azure, inventory Cloud Shell storage accounts and file shares; for leavers, include shell storage in deprovisioning.
Add detections. See Detection and measurement below.
Roll back safely. Each control is reversible: detach the IAM policy or SCP statement, remove the network block, or re-enable the Google setting for a group. Keep the change records so rollback is quick during an incident that needs shell access.

Detection and measurement

Use by unexpected principals: alert on CloudTrail createSession or createEnvironment by principals outside the approved admin group; equivalent CLI activity originating from Azure or Google portal shells by non-admin users.
File transfer events: alert on getFileUploadUrls and getFileDownloadUrls, especially after a new or unusual sign-in. AWS supports an EventBridge pattern with source aws.cloudshell and eventSource cloudshell.amazonaws.com.
Credential creation from a shell: correlate CreateAccessKey or service account key creation with a recent shell session for the same principal.
Sign-in risk then shell use: a risky or new-location console sign-in followed quickly by shell use and permission changes is a strong compromise signal.

Metrics:

Number of principals able to launch a cloud shell, per platform, against the approved list.
Percentage of shell sessions by principals with phishing-resistant MFA.
File transfer events per month and the share investigated.
Credential files found in shell home directories or Cloud Shell file shares during reviews (target zero).
Mean time to detect shell use by an unapproved principal.

Common failure patterns

Assuming the shell is sandboxed from production. It carries the user's full permissions; an administrator's shell is an administrator.
Treating transfer blocking as data loss prevention. AWS itself notes wget still works. Use network isolation where egress matters.
Forgetting persistent storage at offboarding. Azure file shares survive a settings reset, and AWS and Google home directories persist for 120 days after last use.
Blocking only one Azure entry point. Blocking *.console.azure.com leaves VS Code for the Web and Windows Terminal; Microsoft says a support ticket is needed to block all entry points.
No alerting on shell activity. CloudShell events are logged by default in CloudTrail event history, but few teams build rules for them.
Running automation in a personal shell. Scripts that depend on one person's session break when they leave and blur accountability; move them to pipelines with workload identities.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-17 Remote Access; AC-12 Session Termination; AC-2 Account Management; AU-2 Event Logging; SC-7 Boundary Protection	Shells are remote administrative access with sessions, accounts, logs and network boundaries
NIST CSF 2.0	PR.AA-05 Access permissions defined, managed, enforced and reviewed; PR.PS-04 Log records generated for continuous monitoring	Restricting who can launch shells and logging their use
CIS Controls v8.1	Control 5 Account Management; Control 6 Access Control Management; Control 8 Audit Log Management	Admin-only access, MFA and log review
ISO/IEC 27001:2022 Annex A	8.2 Privileged access rights; 8.15 Logging; 8.18 Use of privileged utility programs	A cloud shell is a privileged utility
MITRE ATT&CK v20	T1539, T1078.004, T1552.001, T1098.001, T1528	Threats in the risk table

Practitioner checklist

Inventory who can launch cloud shells on AWS, Azure and Google Cloud, and compare with an approved admin list.
Choose disable, admin-only or isolated mode per platform and document the owner.
AWS: apply Deny statements for cloudshell:* (non-admins), file transfer and, where needed, cloudshell:PutCredentials; consider VPC environments.
Azure: decide on virtual network isolation; block *.console.azure.com where shells are not allowed and raise a support request to cover all entry points.
Google: set Cloud Shell access in the Admin console by group and promote ephemeral mode.
Require phishing-resistant MFA and managed devices for console access.
Ban storing access keys, service account keys and kubeconfig credentials in shell home directories, and review for them.
Build alerts for shell use by unapproved principals, file transfers and credential creation after shell sessions.
Include Cloud Shell storage in leaver processes and data retention.
Check startup files (.bashrc, .customize_environment) during incident response.

Cloud Shell and Console Session Security: Controls for AWS, Azure and Google Cloud