Cloud9 は AWS 環境上に構築可能な開発環境で、簡単に使い捨てができるのでちょっとしたお勉強とか、なんかの書籍に載ってるようなハンズオンを試してみるのに重宝しています。実体は EC2 インスタンスで、（デフォルトでは）未接続状態が 30 分以上続くと自動で停止してくれるのでお財布にも優しいです。
ただ、Cloud9 には一般的にマネジメントコンソール上から接続するのですが、UI が妙に好きではないんですよね。使い捨てできるのは嬉しいけれども、操作感が慣れていないと結構ストレスが溜まるものです。使い慣れたエディタ（VSCode）から、Cloud9 に接続できないものでしょうか。
ググってみると、VSCode の Remote-SSH を使って接続する方法が出てきますが、できれば Cloud9 (EC2) に外部から直接 SSH 接続したくないものです。となると、Cloud9 の場合は Session Manager 経由でも接続可能なので、VSCode から Session Manager の接続を張れればよいわけですね。
実は、英語ではありますが、AWS Blog にてそういった場合の設定方法について紹介されています。本稿では、それを要点だけまとめて日本語にし、あと追加でやっておいたほうがよい設定についても追記します。
ローカル側
SSH 鍵の準備
Cloud9 (EC2) に直接 SSH 接続するわけではないのですが、Session Manager 上の SSH トンネリングにて接続をするので、SSH 鍵自体は必要となります。
ですので、適当に作成しておきます。
$ cd ~/.ssh/
$ ssh-keygen -b 4096 -t rsa -f id_cloud9リモート側
Cloud9 の作成
マネジメントコンソールから適当に作ります。ただし、Environment Type のところでは「Create a new no-ingress EC2 instance …」を選択します。これを選ぶことにより、インバウンド通信を一切許可しない Cloud9 (EC2) が作られ、Session Manager 経由でアクセスすることになります。そのため、「Network Settings (advanced)」のところから、Private Subnet にも配置できる (※1) ようになります。
(※1) Private Subnet に配置する場合は、SSM エンドポイントとの疎通性を確保しておく必要があります。
Cloud9 の設定
（オプション）まずは、必要に応じて認証情報の与え方を変更します。Cloud9 では、デフォルトでは マネージド一時認証情報 というのが用いられるのですが、例えば Private Subnet に配置した場合などは、この認証情報はうまく機能しません。そのため、通常の EC2 のようにインスタンスプロファイルにて権限を与える方式に変更してあげます。具体的には、上記のドキュメント記載の手順を参考にして、Cloud9 の設定画面からマネージド一時認証機能を OFF にします。その後、EC2 にアタッチされている IAM Role (AWSCloud9SSMAccessRole) に適当なポリシーを追加して、権限を与えてあげれば ok です。aws s3 ls コマンドや、aws ec2 describe-instances コマンドを実行して、権限がしっかり与えられているか確認しましょう。
（オプション）次に、必要に応じて EBS ボリュームを拡張します。デフォルトだとストレージにほぼ空きがないので、ちょっと大きなファイルを追加しただけですぐにディスク容量がいっぱいになってしまいます。幸い、ドキュメント にボリュームを拡張するスクリプトが公開されているので、これをありがたく実行すれば ok です。拡張後は、df -f 辺りのコマンドで空き容量を確認できます。
さて、ここからが必須の作業です。まずは、先程作成した SSH 鍵の公開鍵（.pub）の方を Cloud9 側に登録しておきます。以下のコマンドを Cloud9 のターミナルで実行して開かれたファイルの最後に、id_cloud9.pub の内容（ssh-rsa AAABBBCCC…）をコピペして保存すれば ok です。
$ npm install -g c9
$ c9 ~/.ssh/authorized_keys続いて、Cloud9 (EC2) が勝手に停止しない設定が必要です。これは、デフォルトの場合はマネジメントコンソールからの接続が 30 分以上ないと自動で停止する設定（らしい）のですが、これでは VSCode から接続していても自動で停止してしまう（らしい）ので、対処が必要ということです。幸い、元ネタのブログにスクリプトが紹介されているので、そのまま実行してしまいましょう。
$ sudo mv ~/.c9/stop-if-inactive.sh ~/.c9/stop-if-inactive.sh.old
$ curl https://raw.githubusercontent.com/aws-samples/cloud9-to-power-vscode-blog/main/scripts/stop-if-inactive.sh -o ~/.c9/stop-if-inactive.sh
$ sudo chown root:root ~/.c9/stop-if-inactive.sh
$ sudo chmod 755 ~/.c9/stop-if-inactive.shこれで、リモート側の設定は完了です。
ローカル側
AWS CLI の設定
さて、先程 Cloud9 側の環境が済んだので、残りはローカル側の設定です。
まずは、Session Manager 経由で SSH 接続するので、ローカル側では AWS CLI にて SSM の実行権限が必要です（他には EC2 についての権限も必要。後述）。適切に設定しておきましょう。
また、CLI から Session Manager を利用する際は プラグイン を入れておく必要があるので、対応します。
SSH の設定
続いて、SSH 設定が必要です。ただ、その前に、SSH 接続の実行時に EC2 が停止中だった場合に、自動で EC2 を起動するスクリプトを仕込みます。そうすることにより、EC2 の状態に関係なく VSCode から Cloud9 環境に接続することが可能になります。このスクリプトも元ネタのブログに記載があるので、ありがたく使わせてもらいます。
$ curl https://raw.githubusercontent.com/aws-samples/cloud9-to-power-vscode-blog/main/scripts/ssm-proxy.sh -o ~/.ssh/ssm-proxy.sh
$ chmod +x ~/.ssh/ssm-proxy.shただ、このスクリプトは一部修正が必要です。具体的には「AWS_PROFILE」と「AWS_REGION」を書き換えます。前者は EC2 や SSM を実行可能なプロファイルを、後者は Cloud9 (EC2) が存在するリージョンに書き換えて保存すれば ok です。
ここまで来たら、あとは ssh の config ファイルに宛先を登録するだけです。以下のように登録します。
Host cloud9
HostName <Cloud9 の実体の EC2 インスタンス ID>
User ec2-user
IdentityFile ~/.ssh/keys/id_cloud9
ProxyCommand sh -c "~/.ssh/ssm-proxy.sh %h %p"VSCode の設定
さて、あとは VSCode 側で設定して、接続するだけです。まずは拡張機能の「Remote SSH」を入れます。そして、その設定を開いて「Connect Timeout」を 60 秒ほどに増やしておきます。これは、接続時の EC2 の起動待ちの時間を加味する必要があるためです。また、必要に応じて「Config File」のパスを指定しておきましょう (※)。
(※) 私の場合、WSL 環境を使っており、Windows 側にも設定ファイルがあるので、ここで明示的にどちらの設定を使うか指定しています。
すると、左側のメニューの「リモートエクスプローラー」から「SSH Targets」が選択できるようになっており、また、適切な config が参照されていると、そこに “cloud9” という選択肢が現れます。あとはそれを選択して接続すれば、Cloud9 に Session Manager (SSH Tunneling) での接続が行えます。
おつかれさまでした。
