この記事で伝えたいこと（ポイント）
- AWS CloudShellについて説明しているよ
- AWS CloudShellがVPCに対応した話を書いているよ
- 実際に触って確認しているよ
はじめに
この記事ではAWSが提供するAWS CloudShell（以下本文ではCloudShell）を学習していく内容となっています。
主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）
誤りなどがあれば修正していく想定です。
今回はCloudShellの基礎と使い方を見ながらVPCに対応したCloudShellを検証します。
参考：AWS CloudShell now supports Amazon Virtual Private Cloud (VPC)
AWS CloudShellとは
簡単に説明するとブラウザベースで提供されるAWSのインターフェイスです。公式ドキュメントでは以下のように説明されています。
AWS CloudShell はブラウザベースの事前認証済みシェルで、 から直接起動できます AWS Management Console。 AWS Management Console いくつかの異なる方法 CloudShell から に移動できます。詳細については、AWS CloudShellの開始方法を参照してください。
AWSを操作するときに利用できるなんか便利な機能ということだけうっすらわかると思います。
補足：そもそもShellってなんですか
そもそもですが、Shell（シェル）とはなんでしょうか。
原始的な話をするとシェルというのはユーザーとコンピュータのオペレーティングシステム（OS）間のインターフェイスとして機能するプログラムです。
※なお、接続先をKernel（カーネル）と表現する場合もあります。
「え、ユーザーが操作しているものってOSじゃないの」とそう思ったかもしれません。
ユーザーから与えられる処理はOSの前にシェルが処理します。
また、シェルにはさまざまな種類がありますが、ここでは割愛します。
ではAWS CloudShellのShellとは
では、CloudShellも同様にOSを操作するものなのでしょうか。これは半分正解です。
CloudShellはAWSとユーザーの操作を仲介するシェルであるため、OSまたはカーネルを操作するものではありません。
つまりは仲介するという言葉をShellという言葉で表現しているということになります。
AWS CloudShellでできること・できないこと
では、CloudShellでできることはなんでしょうか。公式ドキュメントでは以下のように記載されています。
AWS CloudShell セッション用に作成されたシェルを使用すると、任意のコマンドラインシェルをシームレスに切り替えることができます。具体的には、Bash、 PowerShell、および Z shell。 また、プリインストールされたツールやユーティリティにもアクセスできます。これらには以下が含まれます。git, make, pip, sudo, tar, tmux, vim, wget および zip.
シェル環境は、 などの主要な主要なソフトウェア言語をサポートするように事前設定されています。Node.js また、Python。 つまり、例えば、Node.js また、Python ランタイムインストールを最初に実行しないプロジェクト。 PowerShell ユーザーは を使用できます。.NET Core ランタイム。
これらのファイルを によって管理されているリモートリポジトリ AWS CloudShell にプッシュする前に、 で作成またはアップロードされたファイルをローカルリポジトリにコミットできます AWS CodeCommit。
CloudShellを使えば、おおむねやりたいことはできます。ただし、追加料金なしで利用できる範囲では1GBしか利用できないため、一時的に大きなデータを保存しておいて移行するなどの用途には不向きです。
なお、ドキュメントにもありますが、Dockerの使用についても不向きである可能性が高いです。
VPCとつなげると何が良いのか
なんとなくわかってきたところでハンズオンしていきたいですが、最近になってVPCの対応が発表されました。
参考：AWS CloudShell now supports Amazon Virtual Private Cloud (VPC)
そもそも「CloudShell起動時のネットワークはどうなっているんだ。シェルを解釈して実行しているということはそこにインスタンスがいるんじゃないか」など疑問に思ったと思います。
このアップデートはそういう疑問を解消しつつ、プライベートにシェルを実行できるようになったというものです。たとえば、プライベートにEC2/ECSを起動してSSMのセッションマネージャーを起動するということができるようになります。
つまりは踏み台サーバ的な役割を果たせるということです。
AWS CloudShellに触ってみる
シェル環境を構築する
実際に触って確認してみましょう。まずはAWSマネジメントコンソールを開きます。
今回は東京リージョンで実際にやってみるためTokyoの文字を確認しながら、ターミナルアイコンをクリックします。
すると画面をおおうようにプロンプトが立ち上がります。
AWS CLIを実行してみる
ぱっと実行できて実行してもよいコマンドであれば、なんでもいいですが、今回はS3に関するコマンドとSTSに関するコマンドで試してみましょう。まずはS3でバケットの一覧を表示します。
aws s3 ls
次にSTSのコマンドを実行します。
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text) && echo $AWS_ACCOUNT_ID
問題なく実行結果が表示されたでしょうか。STSを実行した場合は今ログインしているアカウントのアカウントIDが表示されるはずです。
無事に終わりましたらいったん、CloudShellを閉じます。
AWS CloudShellに触ってみる（VPC）
次にパブリックIPが割り当てられていないEC2インスタンスをサブネット上に起動してCloudShellからアクセスします。
検証するにあたっての説明
環境構築で画面ぽちぽちが大変だと思うので今回はCloudFormationテンプレートを用意しました。
このテンプレートを適用してEC2にアクセスします。
CloudShell上にテンプレートを配置する
まずは先ほどと同様にターミナルアイコンをクリックしてCloudShellを起動します。
すると画面をおおうようにプロンプトが立ち上がります。
上記のテンプレートをCloudShell上にコピーします。さまざまな方法がありますが、ここではCloudShellの機能を使ってアップロードします。
ActionsからUpload fileを選択します。
先ほどのec2.ymlをアップロードします。アップロード後に緑のバーが画面に表示されます。
テンプレートを適用する
テンプレートがアップロードされているかどうかを確認します。
ls -la ec2.yaml
実行結果
[cloudshell-user@ip-10-132-80-26 ~]$ ls -la ec2.yaml
-rw-r--r--. 1 cloudshell-user cloudshell-user 2446 Dec 4 11:43 ec2.yaml
テンプレートがアップロードされていることを確認できたため、環境構築のために以下のコマンドを実行します。
aws cloudformation deploy --stack-name ec2 --template-file ./ec2.yaml --tags Name=qiita --capabilities CAPABILITY_NAMED_IAM
実行結果
[cloudshell-user@ip-10-132-80-26 ~]$ aws cloudformation deploy --stack-name ec2 --template-file ./ec2.yaml --tags Name=qiita --capabilities CAPABILITY_NAMED_IAM
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - ec2
[cloudshell-user@ip-10-132-80-26 ~]$
問題なく作成できました。
VPCなしのCloudShellで接続
まずは接続したいEC2を特定します。
export INSTANCE_ID=`aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" --query 'Reservations[*].Instances[*].[InstanceId]' --output text`
そのまま作成されたEC2にSSMで接続してみます。
aws ssm start-session --target $INSTANCE_ID
実行結果
[cloudshell-user@ip-10-132-80-26 ~]$ aws ssm start-session --target $INSTANCE_ID
Starting session with SessionId: {ID}
sh-5.2$
VPCありの接続（CloudShell on VPC）
次にCloudShell on VPCを試してみましょう。まずは環境を作成します。
+をクリックします。
Create VPC environmentをクリックします。
作成画面が表示されますので項目を埋めていきます。
| 項目 | 値 |
|---|---|
| Name | qiita |
| Virtual private cloud (VPC) | MyVPCのVPC ID |
| Subnet | MyPrivateSubnet |
| Security group | ec2-InstanceSecurityGroupA |
Createをクリックします。接続先のEC2特定ですが、先ほどはaws ec2 describe-instancesを利用していました。プライベートのサブネットに作成しているため、以下のコマンドは応答が返ってきません。
export INSTANCE_ID=`aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" --query 'Reservations[*].Instances[*].[InstanceId]' --output text`
インスタンスのIDは別のCloudShellで特定するかインスタンスの一覧から取得しましょう。
インスタンスのIDが特定できたら同様にAWS CLIで接続します。
aws ssm start-session --target $INSTANCE_ID
実行結果
[cloudshell-user@ip-10-132-80-26 ~]$ aws ssm start-session --target $INSTANCE_ID
Starting session with SessionId: {ID}
sh-5.2$
SSMは問題なく接続できます。理由としてはエンドポイントが設定として存在しているためです。
この理屈で言うとS3やSTSのコマンドも通りません。
※お試し用にコマンドを記載しておきます。
aws s3 ls
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text) && echo $AWS_ACCOUNT_ID
実行結果
sh-5.2$ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text) && echo $AWS_ACCOUNT_ID
Connect timeout on endpoint URL: "https://sts.ap-northeast-1.amazonaws.com/"
コマンドを問題なく通すにはどうしたらいいか
いくつか手段がありますが、すぐに思いつく方法としては以下の通りです。
- NATを設定/構築する
- VPCエンドポイントを作成する
あるいは同一ネットワーク内にパブリックなEC2をおいておき、ルートを切ってプライベートサブネットからアクセスするという方法があります。この場合だとEC2が2台必要になります。
使い方やコストに合わせて工夫していきましょう。
まとめ
今回はAWS CloudShellの使い方を実際に触って確認しました。
「AWSの環境に少しだけ触れようかなくらいの用途であれば、AWS CloudShellで十分」という印象を受けました。
閉域アクセスで他のサービスと接続するときはVPCエンドポイントなどを設定して対応しましょう。