AWS経験5年以上の僕が詳しくご説明します。
本記事の内容
- CloudShellの概要
- CloudShellでAmazon Linux 2を起動して操作する
- CloudShellのTips紹介
CloudShellとは
CloudShellはAWSマネジメントコンソールからAmazon Linux 2環境を操作できるサービスです。
本記事ではCloudShellでAmazon Linux 2を起動し、AWS CLIなどを実行する方法を紹介します。
サービス概要
CloudShellのサービス概要は以下のとおりです。
- AWSマネジメントコンソールから1クリックでAmazon Linux 2環境を起動できる
- フルマネージドなのでOSの管理不要
- AWS CLI ver2、ECS CLI、SAM CLI、Python、Nodeなどがインストール済み
- AWS CLI、ECS CLI、SAM CLIはAWSマネジメントコンソールにログインしたIAMユーザーの権限で実行できる
- CloudShellからVPC内に作成したEC2やRDSに直接は接続できない
- 各リージョンで最大10個のセッションを同時に利用可能
- CloudShell自体は無料
CloudShellの環境情報
CloudShellのOS詳細情報は以下の通りです。なお、CloudShellはコンテナ環境になります。(おそらくAWS Fargate上で動作)
種別 | 設定内容 |
OS | Amazon Linux 2 |
CPU | 2コア |
メモリ | 4GB |
swap | 無し |
ディスク | 30GB (ファイルの永続保存は/homeに1GBまで可能) |
デフォルトのOSユーザー | cloudshell-user |
インストール済みパッケージ(抜粋) |
|
ファイルの永続保存について
1GBまでのファイルを/homeに永続保存できます。これは、各リージョンごとに別管理となります。
「永続保存」について、厳密には最後にCloudShellセッションを開始した日から数えて120日間保存されます。
つまり、/homeにファイルを保存したあと、CloudShellを120日使用しなかった場合は自動的に削除されます。(ファイル削除前にパーソナルヘルスダッシュボードを介して通知されます)
120日以内にCloudShellを定期的に使用することで、半永久的に/homeにファイルを保存することが可能です。
/home以外に保存したファイルは永続保存されません。
CloudShellではyumなどでパッケージを追加インストールできますが、通常は/usrなどにインストールされます。
しかし、/usrにインストールしたファイルは永続化されないため、次回CloudShellを使用する際には当該パッケージは削除されていて使うことができません。
その場合は、必要に応じて当該パッケージを再度インストールします。
CloudShellの用途
CloudShellはAWS CLIを実行したり、開発用のスクリプトをテストしたりするために使用できます。
サービスの特性上、長期間の利用を目的とした使い方には適しません。
理由は上述の通りファイルは1GBまで/homeに永続保管できますが、それ以外のディレクトリで作成したファイルは永続化されないためです。
準備
CloudShellを使用するには、AWSマネジメントコンソールにログインしているIAMユーザーにAWSCloudShellFullAccess
ポリシーを設定する必要があります。
AdministratorAccess
かPowerUserAccess
が付与されているIAMユーザーであれば、上記ポリシーの設定は不要です。
CloudShellを起動する
CloudShellを起動する方法は二通りあります。
方法1. CloudShellのアイコンから
ナビゲーションバーに表示されているCloudShellのアイコンをクリックします。1クリックで起動できるのは便利ですね。
方法2. 検索ボックスから
ナビゲーションバーの検索ボックスに「cloudshell」と入力する方法でもCloudShellを起動できます。
起動後の画面
CloudShellを起動すると、最初にサービスの説明画面が表示されます。
次回以降はこの画面を表示したくない場合は「Do not show again」にチェックを入れて「Close」をクリックします。
CloudShell環境が起動するまで1分~1分半程かかるので少し待ちます。
起動完了後は以下の画面になります。
CloudShellで操作できること
CloudShellで操作できる以下の内容について紹介します。
- AWS提供のCLI 3つ
- Python、Nodeなどの各種ランタイム
- yumでパッケージインストール
- インターネットへの接続
- CloudTrailへのロギング
- Actionsボタン
- 設定ボタン
1. AWS提供のCLI 3つ
AWS提供の「AWS CLI、ECS CLI、SAM CLI」は全てインストール済みです。
AWSマネジメントコンソールにログインしているIAMユーザーの権限で、これらのCLIを使用できます。
EC2、RDS、S3、ECSなどを操作できる権限がある場合は、CloudShellからこれらAWSリソースの操作ができます。
設定済みの環境変数を確認すると、デフォルトリージョンも設定されているのでAWS CLIコマンドはすぐに実行可能です。
$ env | grep -i aws
AWS_CONTAINER_CREDENTIALS_FULL_URI=http://localhost:1338/latest/meta-data/container/security-credentials
serverSocket=/aws/mde/.controller/mde.sock
AWS_EXECUTION_ENV=CloudShell
AWS_DEFAULT_REGION=ap-northeast-1
AWS_REGION=ap-northeast-1
AWS_CONTAINER_AUTHORIZATION_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2. Python、Nodeなどの各種ランタイム
以下の各種ランタイム環境やコマンドがインストール済みで、すぐに使用することができます。
- bash
- git
- Python2.x
- Python3.x
- pip
- PowerShell
- Node
- npm
- jq
3. yumでパッケージインストール
CloudShellはsudoが使用可能なので、yumでパッケージをインストールできます。
ただし、/usrなどにインストールされたパッケージは、次にCloudShellを起動する時には削除される点に注意が必要です。理由は、上述のとおり/home以外はデータが永続保管されないためです。
また、CloudShellはEC2などで使用できる一部Linuxコマンドはデフォルトでインストールされていません。必要に応じて、以下などのコマンドに関するパッケージをインストールします。
$ sudo yum install -y ec2-net-utils net-tools bind-utils
パッケージ名 | 代表的なコマンド | 用途 |
ec2-net-utils | ip a | ネットワーク関連の確認 |
net-tools | netstat, route | ネットワーク関連の確認(レガシー) |
bind-utils | dig, nslookup | DNS関連の確認 |
4. インターネットへの接続
CloudShellからインターネットには接続できます。
$ curl http://checkip.amazonaws.com/
CloudShellのグローバルIP
インターネットからはCloudShellに接続できません。
5. CloudTrailへのロギング
CloudShellのイベント履歴はCloudTrailのログに記録されます。
6. Actionsボタン
右上のActionsボタンから操作できることを紹介します。
New tab:同一画面内の右タブにセッションを追加する。✕ボタンをクリックすると閉じる。
Split into rows:同一画面内の下の行にセッションを追加する。✕ボタンをクリックすると閉じる。
Split into columns:同一画面内の右の列にセッションを追加する。✕ボタンをクリックすると閉じる。
Download file:CloudShellからクライアントPCにファイル(フォルダは不可)をダウンロードする。
「Individual file path」に「/home/cloudshell-user/.bash_history」を入力して「Download」をクリックしたところ、問題なくダウンロードできた。
Upload file:/homeにファイルをアップロード(最大1GBまで)する。
「Select file」からクライアントPCで作成した「aaa.txt」を選択し「Upload」をクリックしたところ、問題なくアップロードできた。
Restart AWS CloudShell:「Restart」をクリックするとCloudShellを再起動できる。/homeのファイルは保持される。
再起動は1分半程かかります。以下の処理を行っているようです。
- CloudShellのコンテナを停止
- CloudShellのコンテナを起動
Delete AWS CloudShell home direcrtory:ボックスに「delete」を入力し「Delete」をクリックすると、/homeで作成したファイルが削除される。
/home削除は1分程かかります。以下の処理を行っているようです。
- CloudShellのコンテナを削除
- CloudShellのコンテナを新規作成
コンテナの停止と比べて削除のほうが早いので、「Restart AWS CloudShell」より処理時間は短いです。
7. 設定ボタン
右上の設定ボタンから以下をカスタマイズできまます。「Confirm」をクリックすると設定が反映されます。
- Font size:CloudShell 内のフォントサイズ(5段階)
- AWS CloudShell theme:CloudShellの外観(Light / Dark)
- Enable Safe Paste:クライアントPCからの複数行コピペ時に警告を表示するか
- フォントサイズはデフォルトだと小さいので、僕は「Medium」に変更しています。
- 変更した設定はAWSアカウントに保存されます。次に同一リージョンまたは他リージョンでCloudShellを起動する時も、変更した設定で使用可能です。
CloudShell Tips
CloudShellのTipsや気になる点を調べた内容を紹介します。
- クライアントPCからコピペ可能
- セッションは10個以上起動できる
- コンテナの状況確認
- CloudWatch Logには未対応
- セッション時間
- VPC内のEC2/RDSに無理やり接続してみる
- 別IAMユーザーのアクセスキーを設定
1. クライアントPCからコピペ可能
クライアントPCからCloudShellへコピペできます。もちろん、CloudShell内でもコピペはできます。
クライアントPCから複数行をペーストしようとすると、デフォルトでは警告が表示され「Paste」をクリックするとペーストできます。
コピペミス防止のための機能ですね。
CloudShell内の複数行コピペについては、警告は表示されません。
2. セッションは10個以上起動できる
AWS公式では「CloudShellはリージョンごとに最大10セッションま利用可能」と記載されていますが、それ以上起動できました。
最高で何セッションまで起動できるかは確認していませんが、15個は同時起動できました。また、各セッションが切断されることはありませんでした。
3. コンテナの情報確認
CloudShellはコンテナ環境なので、以下コマンドでコンテナの情報を確認できました。
$ curl http://169.254.170.2/v2/stats
$ curl http://169.254.170.2/v2/metadata
$ curl -sH "X-aws-ec2-metadata-token: $AWS_CONTAINER_AUTHORIZATION_TOKEN" $AWS_CONTAINER_CREDENTIALS_FULL_URI
4. CloudWatch Logsには未対応
CloudShellで実行したOSのコマンド履歴はCloudWatch Logsには保存されません。(2022年3月時点)
5. セッション時間
CloudShellのセッションは非アクティブ状態が20分続くと切断されます。
再びCloudShellを起動すると、再起動完了後(1, 2分ほど)にセッションを利用できます。
6. VPC内のEC2/RDSに無理やり接続してみる
CloudShellからVPC内に作成したEC2やRDSに直接接続することはできません。(2021年4月時点)
今後のupdateでCloudShellから直接VPCのリソースに接続できるようになるとAWSから公表されています。
少し強引ですが、以下の方法でVPC内のEC2/RDSに接続することが可能です。
AWS公式の方法ではないため非推奨となります。もし、接続を試した場合はセキュリティの観点で、変更した設定は必ず戻しておきます。
EC2への接続
1. EC2をパブリックサブネットに作成します。
2. CloudShellでグローバルIPアドレスを確認します。
$ curl http://checkip.amazonaws.com/
3. EC2に割り当てているセキュリティグループのインバウンドに、上記で確認したグローバルIPアドレスに対してSSHのポートを開けるように設定します。
4. EC2で以下を実行します。
# ssh-keygenでCloudShell用の一時的な秘密鍵を作成(対話は全て何も入力せずにEnterキーをクリック)
$ ssh-keygen -f ~/.ssh/id_rsa_cloudshell
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ec2-user/.ssh/id_rsa_cloudshell.
Your public key has been saved in /home/ec2-user/.ssh/id_rsa_cloudshell.pub.
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxec2-user@ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal
The key's randomart image is:
+---[RSA 2048]----+
| xxxxxx |
| xxxxxx |
| xxxxxx |
+----[SHA256]-----+
# EC2のキーペアで使用しているauthorized_keys(公開鍵を設定するファイル)をバックアップ(最後にバックアップから戻すため)
$ cp -p ~/.ssh/authorized_keys ~/.ssh/authorized_keys_back
# CloudShell用の一時的な公開鍵をauthorized_keysに追記
$ cat ~/.ssh/id_rsa_cloudshell.pub >> ~/.ssh/authorized_keys
# CloudShell用の一時的な秘密鍵をcatで表示
# "-----BEGIN RSA PRIVATE KEY-----" と "-----END RSA PRIVATE KEY-----"を含む全行をテキストエディタなどにコピペ
$ cat ~/.ssh/id_rsa_cloudshell
5. CloudShell 上で以下を実行します。
# 一時的な秘密鍵を作成
$ vi ~/a.pem
# テキストエディタにコピーした全行をコピペ
# 一時的な秘密鍵のパーミッションを変更
$ chmod 600 ~/a.pem
# 変数aにEC2のパブリックDNSかIPアドレスを代入
$ a=ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
# SSHで接続("Are you sure you want to continue connecting (yes/no)?"をスキップするオプションを付与)
$ ssh -l ec2-user -i ~/a.pem -o StrictHostKeyChecking=no ${a}
Warning: Permanently added 'ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com,xxx.xxx.xxx.xxx' (ECDSA) to the list of known hosts.
Last login: Fri Apr 30 22:28:13 2021 from xxxxxx
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-xxx-xxx-xxx-xxx ~]$
# EC2に接続できた後はexitでSSH接続を切断する
[ec2-user@ip-xxx-xxx-xxx-xxx ~]$ exit
6. 上記で変更した設定を戻します。
### EC2側
# CloudShell用の一時的な秘密鍵/公開鍵を削除
$ rm ~/.ssh/id_rsa_cloudshell ~/.ssh/id_rsa_cloudshell.pub
# authorized_keysをバックアップから戻す
$ mv ~/.ssh/authorized_keys_back ~/.ssh/authorized_keys
### CloudShell側
# 一時的な秘密鍵を削除
$ rm ~/a.pem
# SSH接続時に自動作成されたファイル/ディレクトリを削除
$ rm ~/.ssh/known_hosts
$ rmdir ~/.ssh/
7. 最後に、EC2に割り当てているセキュリティグループのインバウンドから、今回追加したルールを削除します。
RDSへの接続
1. パブリックアクセスを有効にしたRDSを作成します。今回はMySQLを使用します。
2. CloudShellのグローバルIPアドレスを確認します。
$ curl http://checkip.amazonaws.com/
3. RDSに割り当てているセキュリティグループのインバウンドに、上記で確認したグローバルIPアドレスに対してMySQLのポートを開けるように設定します。
4. CloudShell 上で以下を実行します。
# 変数aにRDSのエンドポイントを代入
$ a=xxxx.xxxxxxxx.ap-northeast-1.rds.amazonaws.com
# mysqlで接続
$ mysql -u admin -p -h ${a}
Enter password: # マスターパスワードを入力
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 1050
Server version: 8.0.20 Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MySQL [(none)]>
# RDSに接続できた後はexitでSQL接続を切断する
MySQL [(none)]> exit
5. 上記で変更した設定を戻します。
### CloudShell側
# mysql接続時に自動作成されたファイルを削除
$ rm ~/.mysql_history
6. 最後に、RDSに割り当てているセキュリティグループのインバウンドから、今回追加したルールを削除します。
7. 別IAMユーザーのアクセスキーを設定
CloudShellはAWSマネジメントコンソールにログインしているIAMユーザーの権限で、AWS関連のCLIを使用することができます。
もちろんaws configure
で別のIAMユーザーのアクセスキーを設定して、その権限でAWS CLIを実行することも可能です。
なお、aws configure
を実行した後は、生成されたCLI設定ファイル/認証情報ファイル/ディレクトリを忘れずに削除しておきます。AWSのセキュリティベストプラクティスでは、アクセスキーの使用は非推奨のためです。
$ rm ~/.aws/config ~/.aws/credentials
$ rmdir ~/.aws/
まとめ
CloudShellはAWS CLIなどを実行する環境として、手軽に利用できる点が素晴らしいですね。
また、CloudShellとEC2を比較した場合、CloudShellは以下の考慮が不要というメリットがあります。(CloudShellはマネージドサービスであるため)
- OSパッチ適用
- セキュリティ対策(不正侵入対策、マルウェア対策など)
- インスタンスの管理(起動、停止、削除など)
一方で、CloudShellは「ファイルの永続保存は/homeに1GBまで」といった制約もあるので、長期利用を目的とした使い方には適しません。
CloudShellとEC2はうまく使い分けていきたいですね。