What Is AWS CloudShell? Browser-Based AWS CLI Explained

Simple explanation

Think of CloudShell as a terminal window that lives inside the AWS website. When you open it, AWS spins up a small Linux machine in the background and gives you a command prompt. That machine already has the AWS CLI installed, and it already knows who you are because you are signed in to the console.

You type commands, AWS runs them, and you see the results. When you close the tab or walk away for too long, the machine is recycled. Your home directory files stick around (up to 1 GB per region), but everything else resets.

CloudShell is not a replacement for all local CLI work. It is a convenience tool for quick interactions with AWS when you are already in the browser.

Why AWS CloudShell matters

Setting up the AWS CLI locally involves installing the tool, configuring credentials, choosing a default region, and keeping everything updated. That is worth doing for daily development work, but it is overhead when you just need to check something quickly.

CloudShell removes all of that friction. You click an icon in the console, and within a few seconds you have a working terminal. Your identity, permissions, and region are already set. This matters most for:

• Quick admin tasks. Checking running instances, listing S3 buckets, or verifying IAM policies.
• Investigation and troubleshooting. Confirming your identity with aws sts get-caller-identity when something is not working, or checking resource state from a known-good environment.
• One-off CLI work. Running a command you do not need to script or repeat.
• Learning. Experimenting with CLI commands without worrying about access key management or local configuration.

How AWS CloudShell works

The workflow is straightforward:

1. You sign in to the AWS Management Console with your IAM user, IAM role, or SSO session
2. You open CloudShell (from the top navigation bar or the service search)
3. AWS creates a temporary compute environment in the region you currently have selected in the console
4. The shell session uses your current console credentials. That means the same IAM identity and permissions you already have. CloudShell does not use separate access keys. Instead, it works with temporary session credentials from your console login
5. The AWS CLI v2 is pre-installed and pre-configured with your region, so commands like aws s3 ls work immediately
6. Your home directory (/home/cloudshell-user) has up to 1 GB of persistent storage in standard environments, but the rest of the compute environment (installed packages, system-level changes) is ephemeral

How to open AWS CloudShell

There are three ways to launch CloudShell:

• Console icon. Click the terminal prompt icon (>_) in the top navigation bar of the Management Console. This is the fastest method.
• Search bar. Type “CloudShell” in the console search bar and select the result.
• Direct navigation. Go to the CloudShell service page from the Services menu.

CloudShell opens in whichever region you have selected in the console. If you need to work in a different region, switch the region selector before opening CloudShell, or pass the —region flag on individual commands:

# Run a command in a different region without switching the console
aws ec2 describe-instances --region us-west-2

What is included in the CloudShell environment

CloudShell runs Amazon Linux 2023. The environment comes with a useful set of tools pre-installed:

Shells

• Bash (the default shell)
• Z shell (Zsh)
• PowerShell

AWS tooling

• AWS CLI v2, pre-installed and pre-authenticated
• Python 3 and pip for running scripts and installing packages like boto3
• Node.js and npm

Utilities

• git for version control
• jq, a JSON processor useful for parsing AWS CLI output
• curl and wget for HTTP requests
• unzip and tar for archives
• vim and nano for text editing

Verify the environment with a few quick commands:

# Check CLI version and your authenticated identity
aws --version
aws sts get-caller-identity

# Confirm the active region
aws configure get region

# Check Python availability
python3 --version

Persistent storage and session behavior

Understanding what persists and what does not in CloudShell prevents surprises.

What persists (standard environments)

In standard CloudShell environments, your home directory (/home/cloudshell-user) has 1 GB of persistent storage per region. Files you save here survive session restarts. This is a good place for scripts, small config files, and reference data.

What does not persist

The compute environment itself is ephemeral. Packages you install with pip, npm, or yum are lost when the session ends. Shell history outside the home directory, environment variables, and any system-level changes are also reset.

Storage cleanup and session timeouts

• Inactive sessions. CloudShell disconnects after roughly 20 to 30 minutes of inactivity. You can reconnect, and your home directory files are still there.
• Unused storage deletion. If you do not use CloudShell in a given region for 120 days, AWS automatically deletes the persistent storage for that region.

# Create a setup script in persistent storage
cat > ~/setup.sh << 'EOF'
pip3 install boto3 --quiet
pip3 install awscurl --quiet
echo "Environment ready"
EOF

chmod +x ~/setup.sh

# Run it at the start of each session
~/setup.sh

When to use AWS CloudShell

CloudShell is the right tool when:

• Quick one-off commands. Listing resources, checking configurations, or running a single CLI command you do not need to save.
• Verifying identity and permissions. Running aws sts get-caller-identity to confirm which account, user, or role you are operating as, especially when debugging access denied errors.
• Confirming region and account state. Checking which region you are in and what resources exist before making changes.
• Troubleshooting from the console. When something looks wrong in the console UI and you want to verify it with the CLI.
• Running short scripts. Small Bash or Python scripts that you do not need a full local setup for.
• Learning the CLI. Experimenting with commands without worrying about local credential setup.

When not to use AWS CloudShell

CloudShell is not the right fit for:

• Long-running work. Sessions time out after inactivity, and you cannot keep a process running in the background for hours.
• Heavy local tooling. If your workflow depends on custom editors, language runtimes, Docker, or a specific OS, a local environment is better.
• Large file workflows. The 1 GB storage limit and lack of fast local disk make CloudShell a poor choice for processing large datasets.
• Scheduled automation or CI/CD. CloudShell is interactive and cannot be triggered on a schedule. Use Lambda, CodeBuild, or GitHub Actions instead.
• Private network access (without VPC configuration). Standard CloudShell cannot reach resources in private subnets. You need to configure a VPC environment, which trades away persistent storage.
• Sustained development. For daily coding against AWS, install the CLI locally where you have full control over your environment.

Common use cases

Confirm your identity

When you are troubleshooting permission issues, the first step is confirming who the CLI thinks you are. This is especially useful when you are debugging IAM access denied errors.

aws sts get-caller-identity

Quick account audit

Check the state of key resources without leaving the browser:

# List running EC2 instances as a table
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[*].Instances[*].{ID:InstanceId,Type:InstanceType,AZ:Placement.AvailabilityZone}' \
  --output table

# List S3 buckets in this account
aws s3 ls

# List IAM roles
aws iam list-roles --query 'Roles[*].RoleName' --output text

Download and inspect a file from S3

Pull a config file or log from S3 to inspect it without downloading to your local machine:

aws s3 cp s3://my-bucket/config.json .
cat config.json | jq .

Run a short Python script

Python 3 and boto3 are available, so you can run quick automation scripts directly:

# save as ~/check_buckets.py and run with: python3 ~/check_buckets.py
import boto3

s3 = boto3.client('s3')
response = s3.list_buckets()
for bucket in response['Buckets']:
    print(bucket['Name'], '-', bucket['CreationDate'])

Test IAM permissions

Quickly verify whether your current identity has a specific permission without leaving the console:

# Try listing secrets to check if you have Secrets Manager read access
aws secretsmanager list-secrets --max-items 1

AWS CloudShell vs local AWS CLI

Both give you access to the same AWS CLI commands. The difference is in setup, flexibility, and where they run.

AWS CloudShell vs Session Manager

These two tools sound similar but serve different purposes.

• CloudShell is a browser-based terminal for running AWS CLI commands against AWS services. It runs on AWS-managed infrastructure, not on your instances.
• Session Manager gives you shell access into a specific EC2 instance or managed server. It replaces SSH by letting you connect through the console or CLI without opening inbound ports or managing key pairs.

Use CloudShell when you want to run AWS API commands (like listing resources or checking IAM policies). Use Session Manager when you need to log into a specific server to check logs, debug an application, or manage the operating system.