CloudShell

Instant browser-based shell with AWS CLI, Python, and common tools pre-installed

AWS CloudShell is a browser-based shell environment that launches instantly with the AWS CLI, Python, Node.js, and common Linux tools pre-installed, and automatically authenticates as the currently logged-in IAM identity - no credentials to configure. It is designed for quick operational tasks, scripting, and CLI exploration directly from the AWS Management Console.

What CloudShell Provides and How It Works

CloudShell gives you a terminal session that inherits the credentials of your current console session. There is nothing to provision - it is available in seconds from the console toolbar.

Feature	Details
Authentication	Inherits current IAM identity from console session - no setup
Pre-installed tools	AWS CLI v2, Python 3, Node.js, git, jq, pip, npm, bash, vim, nano
Persistent storage	1 GB of persistent home directory storage per region
Session duration	Sessions time out after 20 minutes of inactivity
Compute	Shared compute - not for heavy workloads
Availability	Available in most AWS regions from the console toolbar
Custom installs	You can install additional packages - persist to home directory

💡

CloudShell home directory storage (1 GB) persists between sessions - files you create in $HOME are still there when you reconnect. However, software installed outside $HOME (e.g., /usr/local/bin) does not persist. Install tools to $HOME/bin and add it to your PATH in .bashrc.

CloudShell vs Cloud9: When to Use Which

Dimension	CloudShell	Cloud9
Startup time	Seconds - no provisioning	Minutes - EC2 must start
Cost	Free - no EC2 charge	EC2 instance cost (+ EBS)
Compute power	Shared, limited	Dedicated EC2 (t3.micro to larger)
IDE features	Terminal only	Full code editor, debugger, file tree
Persistent storage	1 GB per region	EBS volume size you choose
VPC access	No direct VPC access	Can be placed in a VPC
Docker support	No (no privileged access)	Yes, with instance profile
Lambda debugging	No	Yes, with SAM CLI integration
Collaboration	Single user	Multi-user real-time editing
Use case	Quick CLI tasks, ops, scripting	Active development, debugging

Choose CloudShell for: checking resource states, running one-off CLI commands, quick scripting tasks, and situations where you have console access but no local AWS CLI.

Choose Cloud9 for: active software development, Lambda debugging, team collaboration, and when you need persistent compute with VPC network access.

File Upload, Download, and Cross-Region Use

CloudShell supports uploading and downloading files via the Actions menu in the console, useful for moving scripts and configs in and out of the shell session.

bash

# Common CloudShell patterns

# Install a tool to persistent home directory
curl -Lo $HOME/bin/kubectl "https://dl.k8s.io/release/$(curl -Ls https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x $HOME/bin/kubectl
export PATH=$HOME/bin:$PATH  # add to .bashrc for persistence

# Quick script with jq
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,State:State.Name}' \
  --output json | jq '.[][] | select(.State == "running")'

# Cross-account operation using role assumption
STS=$(aws sts assume-role --role-arn arn:aws:iam::OTHER_ACCT:role/MyRole --role-session-name shell)
export AWS_ACCESS_KEY_ID=$(echo $STS | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $STS | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $STS | jq -r '.Credentials.SessionToken')

⚠️

CloudShell does not have direct VPC access - it runs in an AWS-managed network. You cannot reach private RDS endpoints, EC2 instances in private subnets, or internal load balancers from CloudShell. Use Systems Manager Session Manager or EC2 Instance Connect for accessing private instances.

Limitations and Gotchas

Limitation	Impact	Workaround
No VPC access	Cannot reach private resources	Use SSM Session Manager or a bastion host
Shared compute	CPU/memory throttling for heavy workloads	Use Cloud9 or a dedicated EC2
20-min inactivity timeout	Long-running scripts may be interrupted	Use nohup or run in background with &
1 GB storage limit	Large repos or datasets exceed limit	Use S3 as intermediate storage
No Docker	Cannot build or run containers	Use Cloud9 with privileged mode
Region-specific home dir	Files in us-east-1 not visible in eu-west-1	Use S3 for cross-region file sharing
Session timeout (20 min idle)	Shell process exits, background jobs killed	Structure scripts to be resumable

🎯

Interview Focus Points

1How does CloudShell authenticate - what credentials does it use?
2What is the persistent storage model in CloudShell and what are the limits?
3How does CloudShell differ from Cloud9 and when would you choose each?
4What are the main limitations of CloudShell compared to a full development environment?
5Can you access VPC resources from CloudShell? If not, what alternative would you use?
6How would you install and persist a custom tool in CloudShell across sessions?