 本記事は 夏休みクラウド自由研究 8/17付の記事です。 |
こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。
昨日の寺内の記事で、VPC環境に AWS CloudShell を作成し、ネットワークまわりのテストにも使用できそうだという話が出ていました。本記事では、ネットワークテストツールとしてCloudShellを利用できるのか、という観点でもう少し考察してみることにします。
VPC環境にCloudShellを作成する手順については、上記記事をご覧ください。
ネットワークコマンドを試してみる
さっそく、VPCに作成されたCloudShellで、代表的なネットワークコマンドを試してみることにします。
ping
もちろん、インストールされています。
スクリーンショットを見ても分かるわけがないのですが、実はあて先のIPアドレスはもうひとつ起動したCloudShellです。寺内の記事にあった通り、VPC環境CloudShellはIAMユーザごとに2つまで作成できるので、CloudShellのみでエンド・トゥ・エンドの疎通確認を行うことが可能です。(セキュリティグループでpingを許可する必要がある点に注意)
curl
curlもインストールされています。
なお、CloudShellは、DNSとしてAmazon Provided DNSを参照しているので、DNS名前解決をすることができます。
dig
dig はインストールされていません。また、nslookup もインストールされていません。EC2用のAmazon Linux 2023 AMIにはインストールされていましたので、CloudShell化の際に落とされてしまったコマンドなのでしょう。
DNS名前解決の動作確認は個人的には必須と思っているので、digが使えるように、リポジトリからパッケージをインストールしてあげることにします。
その他のコマンド
EC2用Amazon Linux 2023には入っていた tcpdump は入っていませんでした。また、EC2用Amazon Linux 2023に入っていなかった telnet や nc (netcat)も、もちろん入っていません。
これらのコマンドも必要に応じてインストールできるといいですよね。
リポジトリにアクセスする方法を考える
CloudShellの /etc/yum.repos.d/amazonlinux.repo を見ると、ミラーリストにcdn.amazonlinux.com が指定されています。これはインターネット上のサイトなので、CloudShellからインターネットへ接続できるようにする必要があります。
インターネットに接続する
NATゲートウェイ経由
NATゲートウェイ経由でインターネットに接続可能なサブネットにCloudShellを作成した場合、特に考えることはありません。CloudShellもサブネットに設定されたルートテーブルに従って通信するため、NATゲートウェイ経由でインターネットに接続することができ、Amazon Linux 2023のリポジトリを参照することができます。
パブリックIPを持たせる
パブリックサブネットにCloudShellを作成した場合ですが、CloudShell作成時に自動でパブリックIPが割り当てられることはありません。そのため、寺内の記事にある手順でCloudShellのENIを特定し、「アクション」→「アドレスの関連付け」からパブリックIPを関連付けてあげる必要があります。パブリックIPを関連付けると、インターネットに接続することができるようになり、Amazon Linux 2023のリポジトリを参照することができます。
S3 VPCエンドポイントに接続する
次に、インターネット接続が全くできないサブネットに配置したCloudShellを考えます。
通常のAmazon Linux 2023では、S3エンドポイント(s3.dualstack.ap-northeast-1.amazonaws.com など)に接続できればリポジトリにアクセスできるようになっていますが、前述の通り、CloudShellのリポジトリ設定では、cdn.amazonlinux.comを参照しており、S3エンドポイントを参照していません。
そこで、EC2 Amazon Linux 2023に設定された /etc/yum.repos.d/amazonlinux.repo の内容で、CloudShellの /etc/yum.repos.d/amazonlinux.repo の内容を置き換えてあげます。どちらもAmazon Linux 2023のリポジトリなので問題はないはず……と試してみると、問題なくリポジトリを参照することができました。
インターネットに接続できないサブネットに作成したCloudShellでも、S3 VPCエンドポイント(ゲートウェイ/インターフェイス)にアクセスできるようになっていればリポジトリへのアクセスは問題なさそうです。(※)
パッケージをインストールする
リポジトリにアクセスできるようになったら、パッケージを入れていきます。
通常のパッケージインストールと何ら変わりないので、詳細は割愛しますが、bind-utilsパッケージをインストールすることでdigコマンドを(ついでにnslookupコマンドも)実行できるようになりました。
制約事項の確認
ここからは、VPC環境CloudShellを使っていて分かった制約事項の類を解説していきます。
制約事項：インアクティブ状態になってから20～30分でセッションが終了する
まず、VPC環境特有の話ではありませんが、CloudShellを使わずに20～30分おいておくと、セッションが終了します。セッション終了時の挙動が、通常のCloudShellとVPC環境CloudShellでは異なり、VPC環境CloudShellはだいぶ厳しい制約があることが分かりました。
セッションが終了すると変更したデータは初期状態に戻る
通常のCloudShellは、ホームディレクトリは永続ストレージになっておりセッションが終了してもデータは削除されませんが、VPC環境CloudShellではセッション終了時にホームディレクトリのデータも削除されます。
また、ホームディレクトリ以外の変更（例えば /bin にインストールしたコマンドなど）も元に戻ってしまいます。
そのため、せっかくパッケージをインストールしてもセッションが終了すると一からやり直しになります。
セッションが終了するとネットワークインターフェイス(ENI) IDが変わる/プライベートIPが変わる
一度セッションが終了し、CloudShellを再起動すると、ネットワークインターフェイスIDが変わってしまいます。また、プライベートIPも変わってしまいます。そもそもVPC環境CloudShellを作成するときにIPアドレスは指定できませんでした。
環境によっては、サブネットサイズよりも狭い範囲(例えば1 IP単位)で通信をフィルタリングしなければならないこともあると思いますので、この仕様はうれしくありません。
ただしこれについては、ENIにセカンダリIPを割り当てることができるので、明示的にアドレスを指定してセカンダリIPを割り当てたのちにOS側でIPアドレスを設定してあげれば、特定のIPアドレスを使って通信させることが可能です。
ENIとパブリックIPの関連付けが解除される
セッションが終了したときにENIがなくなってしまっているので、CloudShellを再起動して新しいENIが作られたときにはパブリックIPが関連付けられていない状態になってしまいます。
面倒ですが、セッションが終了してしまった時にはおとなしく再設定してあげるしかなさそうです。
制約事項：ファイルのダウンロード/ファイルのアップロード機能がない
デフォルトのCloudShellで使えたファイルのダウンロード/ファイルのアップロード機能が使用できません。
sftp/scpコマンド、CodeCommitを使うためのgitコマンド、S3を使うためのAWS CLIなどが入っているので、これらで代用することを考えましょう。
まとめ
本記事では、ネットワークテストツールとして使用するという視点でCloudShellを見てきました。
OSにAmazon Linux 2023を使っているだけあって、リポジトリにアクセスできてしまえば思う存分ネットワークテストに活用できそうですね。
一方、インターネットにもS3エンドポイントにもアクセスできない環境に作成する場合、ネットワークテストツールとして使うにはインストールされているコマンドが少なすぎる印象です。とはいえpingとcurlが使えて、pingに応答してくれるだけで十分助かる場面はありそうです。
また、永続ストレージがなくセッションが終了してしまうとディスクへの変更がすべて失われてしまうのは大きな制約と言えます。しかし永続ストレージについては今後の機能追加が期待できると思いますので、これについては時間の問題と言えるかもしれません。