こんにちは、技術1課の加藤です。 今回は Cloud 型 IDE (統合開発環境) サービスである AWS Cloud9 のアップデートをご紹介します！
ラジオ感覚放送「毎日AWS」でも取り上げました。 概要を軽く把握したい、という方はこちらの動画をご利用ください。 音声のみで、簡単にアップデートの紹介をしています。(04:40 あたりから話してます)
AWS Cloud9 の拡張 VPC サポート
紹介するアップデートはこちらです。 AWS Cloud9 が拡張 VPC サポートをリリース
詳しくみていきましょう。
AWS Cloud9とは
AWS Cloud9 とは？ という疑問についてはこちらのページをご覧ください。
簡単にいうとネットワーク越しに高性能なIDEを利用することができる、いわゆる Cloud IDE と呼ばれる種類のサービスになります。
拡張VPCサポートとは
拡張 VPC とは...という感じだと思いますが、わかりやすく言い直すと「 Cloud9 をプライベートな環境で立ち上げることできるようになった」というのが今回のアップデート。
今まで Cloud9 を利用する際には、必ず
- Public IP を持っている
- SSHポートへのインバウンド接続ができる
ことが必要でした。パブリックな環境で利用する必要があり、インターネットに出ずに利用する、ということはできません。
しかし Systems Manager と統合し、SSH接続を利用せずに Cloud9 にアクセスできるようになったことで、プライベート環境で利用することが可能になりました。
ただ「プライベート環境」と言ってもやや曖昧なので、本ブログではこれがどんな環境を指すのか、もう少し丁寧にみていこうと思います。
事前準備
Cloud9 の実態は EC2 なので、EC2インスタンスを起動させるネットワーク環境を用意してあげる必要があります。
ネットワーク
今回はとりあえず、IGWをアタッチした VPC に、パブリックサブネット一個を用意しておきました。(詳細な設定方法はここでは省きます)
このサブネットにインスタンスを立ち上げ、いろいろと設定を変更しながら Cloud9 が利用できるか確認していきましょう。
Cloud9環境
では Cloud9 環境を立ち上げましょう。 マネージメントコンソールの AWS Cloud9 のページから [Create environment] を選択します
[Name] を入力し [Next step] を選択します
以下の設定値を変更し [Next step] を選択します
- Environment type
- Create a new no-ingress EC2 instance for environment (access via Systems Manager) を選択
- Network (VPC)
- 作成した VPC を選択
- Subnet
- 作成した Subnet を選択
次の画面で作成するリソースの確認が表示されます。
この時、SSMを利用するための権限がインスタンスのロールとして作成されることが確認できます。 (スクリーンショットを取得するのを忘れてしまいました...)
[Create environment] を選択して Cloud9 を立ち上げましょう。
作成が完了すると [Your environments] に作成した環境が表示されますので、 [Open IDE] を選択してアクセスしましょう。
Welcome ページが開けば作成完了です。
実験
では今回作成した環境を用いてどんな環境であれば動くのか、確認を行っていきます。
初期値
- EC2 インスタンスに紐づけられたロール権限
- ポリシー: AWSCloud9SSMInstanceProfile
- EC2 インスタンスに紐づけられた SG のインバウンド / アウトバウンド
- インバウンド: なし
- アウトバウンド: すべて許可
- EC2 の所属しているサブネット
- パブリックサブネット (IGW へのルートあり)
実験結果
いろいろと変更を入れて挙動を確認してみました。
- ロールのポリシーを外す
- SSM が使えなくなるためCloud9へのアクセスが不可能
- EC2 インスタンスに紐づけられた SG からアウトバウンド許可を削除
- SSM は使えるためCloud9へのアクセスは可能
- インターネットアクセスは不可能
- ルートテーブルから IGW 削除 (プライベートサブネットにする)
- SSM が使えなくなるためCloud9へのアクセスが不可能
- IGWへのルートを削除、SSMのVPCエンドポイントを用意
- SSM は使えるためCloud9へのアクセスは可能
- インターネットアクセスは不可能
結論
- 基本、挙動は SSM Session Manager と同じ
- EC2 インスタンスに SSM を利用する権限が必要
- EC2 インスタンスが SSM の API を利用できる必要がある
- VPCエンドポイント経由で利用することは可能
- ただしインターネットアクセスができないためパッケージインストールなどで問題あり
まとめ
プライベート環境で立ち上げ可能、ということでしたが、
- SSM Sessoin Manager を使うための要件を満たす必要がある
- インターネットアクセスを拒否するとパッケージインストールが難しい
ことを考えると、SGは閉じつつインスタンスはパブリックな場所に置く、くらいの使い方がちょうど良いのかな、という印象です。
パッケージ落とせないと開発環境としては使いにくいですし、AWS Toolkit を利用したAWSリソースの管理もできなくなってしまいます。 完全にプライベートな環境におくのは、まだちょっと難しそうですね。
