結論
CloudShellがVPC内で使用可能になり、CloudShellを通じてアクセスすることで、踏み台サーバーの必要性はなくなりました。
CloudShell とは
2020年12月16日にAWSのコンソールに追加された機能で名前の通りシェルが使えます。
AWS CLIなどがあらかじめインストールされており、AWS CLIを使うのに便利です。事前にログインしているIAMの権限がそのまま使えるので、アクセスキーの設定などの初期設定が不要です。mysqlクライアントなどよく使うコマンドはあらかじめ入っています。
https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/welcome.html
RDSアクセス時の踏み台
昨今のコンテナ化により、webサーバのシェルに触れることが少なくなってきました。こうなると困るのが、web経由でなく直接クエリをRDSに入れたい場合などに、どこからクエリを入れるかです。サーバを自前で持っていた時はwebサーバにmysqlコマンドを入れて、webサーバとDBへの踏み台機能を兼ねるといったことができましたが、コンテナでは難しいです。
場合によってはコンテナ内に入りmysqlクライアントをインストールすることで対応することもできますが、コンテナにシェルが入っていないことも多く、あまり現実的ではないです。
CloudShellのVPCサポート(CloudShell VPC environment)
CloudShellはVPC内に設置されないため、プライベートネットワーク内のリソースにアクセスすることはできませんでしたが、2024/06/26のアップデートでVPC内のサブネットに上でCloudShellを動かせるようになりました。また、セキュリティグループを持つこともできるのでRDSのセキュリティグループでよくやる、特定セキュリティグループを持つリソースからのアクセスのみを許可するといった設定がされているRDSにも設定変更なしでアクセスすることができます。
https://aws.amazon.com/jp/about-aws/whats-new/2024/06/aws-cloudshell-amazon-virtual-private-cloud/
実際に使ってみる
-
CloudChellを起動
-
VPC内CloudShellを作成
-
作成するCloudShellのネットワークを設定、Createをクリック
-
mysqlコマンドでRDSにアクセス
困りどころ
上記の通り、RDSにアクセスする環境を比較的簡単に作成することができましたが、これで万事完結とはいきません。
ローカルツールからのアクセス
mysqlには多くのクライアントツールがありますし、場合によってDBの情報をローカルで処理して結果を取得するコマンドなど作っている場合もあります。こうしたツールはSSHを使った踏み台には対応していますが、CloudShellのことまでは想定していないと思います。またCloudShell自体もブラウザからのアクセスのみを想定しているのか、SDKやCLIが提供されていません。
なのでローカルツールからアクセス必要がある場合は引き続き踏み台サーバが必要になります。
ファイルのダウンロード、アップロードができない
S3を経由してダウンロード、アップロードするなど回避策はありますが、CloudShellのようにアクションからファイルをダウンロード、アップロードできません。
最大2つまでしか設定を保存できない
1つのIAMアカウントあたり2つしか設定が保存できません。なので3つ以上のVPCを使っている場合、必要に応じて削除して作り直す必要があります。自分の場合、環境ごとにVPCを分けており3環境あるので、CloudShell VPC environmentを作ってない環境に接続しようとするたびに設定を削除して作り直しが必要なので、地味に不便です。
まとめ
制限はあるものの、特に問題なければ踏み台にはCloudShell VPC environmentを使うのが便利だと感じました。自分たちで踏み台サーバを作る場合、踏み台サーバのセキュリティ対応など自分たちサーバの面倒を見なくてはならなず、せっかくコンテナ化しても管理しなくてはいけないサーバが残ってしまっていました。またコスト面でも、使う度サスペンドするか、諦めてサーバを常時立ち上げておくか、Cloud9(サービス終了予定)を使うかなど、といった細かい工夫が必要なり手間をかかるか、コストを呆れめるかの二択でした。CloudShellは基本的には無料なので、コスト面でもメリットがあります。