AWS CloudShell

AWS CloudShell は、AWS マネジメントコンソール上のブラウザから直接利用できる、認証済みのシェル環境です。AWS CLI をはじめ、Python や Node.js などのランタイム、各種開発ツールがあらかじめインストールされており、ローカル端末にツールを導入したり認証情報を設定したりすることなく、ログインしたユーザーの権限でそのままコマンド操作を始められます。

解決する課題

AWS をコマンドラインから操作するには、通常はローカル端末に AWS CLI をインストールし、アクセスキーや一時認証情報を設定し、必要なバージョンのランタイムやツールをそろえる必要があります。チームの端末ごとに環境が異なると、手順の再現性が損なわれたり、長期的な認証情報の管理がセキュリティ上のリスクになったりします。

CloudShell は、コンソールにログインしていればワンクリックで起動でき、その時点のサインインユーザーの権限を引き継いだシェルを提供します。これにより、ローカルへのツール導入や認証情報の配布という準備作業から解放され、手元に開発環境がない状況でも一時的な調査や運用作業をすぐに行えます。AWS が環境を管理するため、利用そのものに追加料金はかからず、コンピューティングとストレージの基本的な範囲は無償で提供されます。

主要概念と用語

• セッション: ブラウザで CloudShell を開いてから操作している間の実行環境。一定時間操作がないと自動的に終了する。
• ホームディレクトリ: ユーザーごとに割り当てられる永続ストレージ領域。スクリプトや設定ファイルを保存しておくと、次回起動時にも残る。
• プリインストールツール: AWS CLI、Python、Node.js、Git、各種パッケージ管理ツールなど、あらかじめ用意された実行環境。
• 権限の継承: コンソールにサインインしているユーザーやロールの権限をそのまま使ってコマンドを実行する仕組み。別途のアクセスキー設定が不要になる。
• VPC 環境: CloudShell をユーザーの VPC 内のサブネットに接続して起動する形態。VPC 内のプライベートなリソースへ到達できる。
• ファイルのアップロード／ダウンロード: ブラウザ経由でローカル端末と CloudShell の間でファイルをやり取りする機能。

仕様・制限・クォータ

通常の CloudShell 環境には、利用者ごと・リージョンごとに 1 GB の永続領域が $HOME として無償で割り当てられます。そのリージョンで 120 日間起動しないと削除対象になります。ホーム外の一時領域はセッション終了時に失われ、VPC 環境には永続領域そのものがありません。

キーボードまたはポインター操作が 20〜30 分ないセッションは終了し、操作を続けても約 12 時間で終了します。実行中プロセスだけでは対話と見なされません。既定ではアカウント・リージョンあたり同時 10 シェル、利用者あたり VPC 環境 2 個までです。外部から着信できる公開 IP や待受ポートもないため、常駐処理には使いません。

内部の仕組み

横にスクロール

CloudShell を起動すると、AWS が管理するコンピューティング環境上にユーザー専用のシェルが用意され、そこにホームディレクトリの永続ストレージがマウントされます。シェルはサインイン中のユーザーまたはロールの権限と結び付き、AWS CLI を実行すると、その権限の範囲内で API が呼び出されます。長期的なアクセスキーを保持せず、コンソールのセッションに連動した認証で動作するため、認証情報をファイルに置く必要がありません。

通常環境では、セッション終了後もリージョン別のホーム領域だけが保持され、次回起動時に再びマウントされます。VPC 環境では指定したサブネットとセキュリティグループに ENI が作られますが、$HOME は一時領域で、20〜30 分の無操作終了または環境削除時に消えます。

設計パターン / ベストプラクティス

CloudShell は、一時的な調査、運用上の確認、ちょっとしたスクリプト実行といった軽量な作業に向いています。よく使うスクリプトや設定はホームディレクトリに置き、必要なツールの追加導入は起動時に実行するセットアップスクリプトにまとめておくと、セッションをまたいでも同じ環境を素早く再現できます。

VPC 内のデータベースや内部エンドポイントへアクセスして確認したい場合は、VPC 環境として CloudShell を起動すると、踏み台サーバーを別途立てずに到達できます。一方で、CI/CD のような自動化や、長時間・高負荷の処理は CloudShell の用途ではないため、CodeBuild やパイプライン、専用のインスタンスなど目的に合ったサービスを選びます。

運用・監視

CloudShell から実行した AWS API 呼び出しは、サインインしているユーザーやロールの操作として証跡に記録されます。誰がどの操作を行ったかを後から監査でき、通常のコンソール操作や CLI 操作と同じ枠組みで追跡できます。

組織として利用を制御したい場合は、IAM ポリシーで CloudShell の起動可否やファイルの入出力を制限できます。たとえば、機密性の高い環境ではファイルのアップロードやダウンロードを禁止する、あるいは CloudShell 自体の利用を特定のユーザーに限定するといった運用が考えられます。日常的な運用タスクをホームディレクトリのスクリプトとして整備しておくと、手順の属人化を抑えられます。

コスト

CloudShell の利用自体には追加料金がかからず、コンピューティングとホームディレクトリのストレージは基本的な範囲が無償で提供されます。このため、軽量な運用作業や学習用途で気軽に使えるのが利点です。

ただし、CloudShell から呼び出した先のサービスでリソースを作成・起動すれば、そのサービスの料金は通常どおり発生します。また、CloudShell を経由するデータ転送には、AWS の標準的なデータ転送料金が適用される場合があります。無償の範囲を超える使い方や付随する料金の扱いは変動するため、最新の料金ページで確認してください。

セキュリティ

CloudShell の大きな利点は、長期的なアクセスキーをローカルやファイルに保持せずに AWS を操作できる点です。実行権限はサインイン中のユーザーまたはロールに連動するため、最小権限の原則に沿って IAM 側で権限を絞れば、CloudShell から行える操作もその範囲に限定されます。

ファイルのアップロードやダウンロードを介した情報の持ち出し・持ち込みを制御したい場合は、IAM ポリシーで該当する操作を制限できます。VPC 環境として起動すれば、外部インターネットを経由せずに内部リソースへアクセスする閉域寄りの構成も取れます。共有端末などからコンソールにサインインして利用する際は、セッションの取り扱いに注意し、不要になったセッションは終了させてください。

関連サービス・比較

CloudShell とよく比較されるのは、クラウド上の統合開発環境である AWS Cloud9 です。どちらもブラウザから使える AWS 上の作業環境ですが、CloudShell が認証済みのシェルを手軽に提供するのに対し、Cloud9 はエディターやデバッグ機能を備えた本格的な開発環境を提供する点が異なります。

ハンズオン / CLI例

CloudShell はブラウザ上のシェルなので、起動後はそのまま AWS CLI を実行できます。以下は、CloudShell 内で権限や設定を確認し、ホームディレクトリにスクリプトを残しておく例です。

# 現在のユーザー／ロールと、操作対象リージョンを確認
aws sts get-caller-identity
aws configure get region

# S3 バケットの一覧を取得（サインインユーザーの権限で実行される）
aws s3 ls

# 起動時に使うセットアップスクリプトをホームディレクトリへ保存
cat <<'EOF' > ~/setup.sh
#!/usr/bin/env bash
# 追加ツールの導入や環境変数の設定をここにまとめる
echo "CloudShell environment ready"
EOF
chmod +x ~/setup.sh

# 次回以降は保存したスクリプトを実行して環境を再現
~/setup.sh