💡

Cloud9の運用を検討する

2022/08/17に公開

AWS

Cloud 9

tech

Cloud9

AWSで提供される統合開発環境（IDE）です。
AWS上でアプリ開発やインフラ管理などに利用でき、また操作環境・端末を限定する用途で用いたり、且つ操作ログをCloudWatchに出力できたりと何かと便利なサービスです。
本記事はCloud9を運用の場面で使う際の考慮、検討内容を記載します。

システム運用におけるCloud9の利用

前提

ある程度縛りがあるほうが考えやすいので、Cloud9はプライベートネットワークに配置する前提とします。そのためCloud9のインスタンスはEC2を利用したSystems Manager（SSM）経由のアクセスとなります。
また、その他のシステム要件として下記を前提とします。

ユーザーが限定できること
監査ログを取得すること
パッチ適用すること
コストを最適化すること
データ保管は行わずバックアップは不要

ユースケース

以下のようなユースケースを想定します。

プライベートネットワーク内のRDSインスタンス等にアクセスするメンテナンス用途、踏み台サーバー用途（Cloud9上で開発を行うわけではない）

Cloud9の検討項目

Cloud9を運用するにあたり、検討すべき項目を下記に記載します。

Cloud9の構成
Cloud9の作成
ユーザー割り当て・変更・削除
パッチ適用
ログ確認
AWS CLIの実行
使用ルール
環境削除

次から各検討ポイントの内容を記載します。

Cloud9の構成

Cloud9を誰のために・どこに・何台準備するか。

検討の観点としては次の2点が挙げられます。

ユーザーロール単位
- 管理者権限を持つグループとReadOnlyなど限定された権限を持つグループ毎にCloud9のインスタンスを分ける
- 機密情報などを操作する場合は共用不可でユーザー毎にインスタンスを準備することも考えられる
- 各インスタンスに付与するIAMロールでAWSリソースの操作をコントロールすることができる
ネットワーク環境単位
- サブネット毎にアクセス制御をするような場合、DBアクセス用Cloud9インスタンス、アプリ管理用Cloud9インスタンスというようにインスタンスを分けることも想定される

Cloud9の作成

Cloud9を常に設置しておくか、必要に応じて作成するかについて検討します。

	メリット	デメリット
常時設定	使いたいときにすぐに利用可能都度設定変更は不要	コストがかかる未使用時は停止しておくといった対策は可能 OSのパッチ管理が必要
必要に応じて作成	コストが安く済む	設置に多少の時間がかかるシステムの変更管理とみなされると変更処理が大変

ユーザー割り当て・変更・削除

各Cloud9インスタンスにどのユーザーを割り当てるかを管理する必要があります。また、ユーザーを割り当てるためにはあらかじめIAMユーザーを準備しておく必要があります。Cloud9はIAMグループ単位で割り当てることができないため、IAMユーザーごとに割り当てる必要があります。
ユーザーと割り当てるCloud9インスタンスの管理は別途管理表など作成するか、検討が必要になります。

なお、Cloud9の利用には次の権限が必要になります。

Cloud9で共有設定を許可されたIAMユーザーかどうか
Cloud9を操作するIAM権限を持っているかどうか
そのため、通常時はReadOnlyの権限しかもたないような権限設定の運用を行う場合、予めCloud9の操作権限を別途割り当てておくなど検討が必要になります。

パッチ適用

Cloud9へのパッチの適用について検討します。
前提としてプライベートサブネットに配置するとしているが、セキュリティの観点から最新パッチが提供された場合は適用することが望ましい。Cloud9は自動パッチ適用の機能があるため、この仕組みを利用するのがお手軽と言えます。

なお、パッチの適用にはインターネットへのアクセスが必要になります。インターネットへの接続が無い完全プライベートな環境で自動パッチ適用を確認したところ少なくとも下記2点のアップデートに失敗していることが確認されました。

EPELのリポジトリからインストールされたパッケージ
Hashicorpのリポジトリからインストールされたパッケージ
Cloud9はIDEを提供しており、上記パッケージはそのIDEに関係するものと思われます。
※上記は2021年末の情報なので、詳しくは実機もしくはサポート等に確認いただきたい。

そのため、インターネットへの接続が無いプライベートネットワーク環境にCloud9を構築する際は、手動でのパッチ適用が必要になる。こちらもマニュアルの記載まで確認ができていないため、実際に検証が必要になります。

ログ確認

ここからは少し毛色が違う話になります。
Cloud9を利用した際のコマンド実行などの操作ログを取得する要件への対応の話となります。Cloud9といえばブラウザから利用できるIDEの画面を想像しがちだが、現状ではIDE上のターミナルの操作ログは自動で取得することができません。そのため、操作ログを取得する場合はSSMセッションマネージャーを利用する必要があり、Cloud9のインスタンスにSSMでアクセスして操作することになります。SSMでアクセスして操作したログはCloudWatch Logsに記録されます。

AWS CLIの実行

Cloud9上でAWS CLIを実行する時、AWS Managed Temporary Credentials（AMTC）という仕組みがあり、Cloud9上で一時的な認証情報を使用することができます。ただしプライベートネットワークからの実行には制約があるため、AMTCではなくインスタンスプロファイルを利用することを検討する必要があります。このあたりクラスメソッド社のブログ記事が大変参考になります。

Cloud9を複数のユーザーで共有する場合については、AMTCの機能を利用するか、各ユーザーのAPIキーを利用するのか（Cloud9利用ユーザー間で共有されるため望ましくない）、検討が必要になります。

使用ルール

Cloud9の利用方法などルールについて検討します。
コスト最適化のため、Cloud9を利用する際に起動して、利用終了時には停止するというルールを定めることが良いと考えられる。Cloud9には利用停止後に時間指定でインスタンスを停止するという機能があるので、こちらの機能を利用するのが便利です。
その他Cloud9の使い方として、Cloud9上に業務に必要なデータを保持するかどうかを検討する必要があります。データが重要なものであればバックアップの取得も考慮する必要があります。本記事ではCloud9は踏み台サーバー用途としているので、Cloud9上には重要なデータは置かないというルール決めでバックアップを不要とする選択肢もあります。Cloud9にはファイルリビジョン履歴機能があるため、ファイルであれば復元することは可能です。

環境削除

Cloud9の削除について検討します。
Cloud9の利用が完了もしくは不要になった場合、Cloud9インスタンスを削除します。Cloud9を削除したら、インスタンスに紐づき設定されたセキュリティグループなど忘れずに削除が必要になります。

さいごに

本記事ではCloud9を踏み台サーバー用途に利用するケースについて、運用面に着目した話を記載しました。踏み台サーバー用途であればCloud9でなくてもEC2を立てSSHもしくはSSMセッションマネージャーを使ってアクセスするという方法もあります。利用要件に応じて使い分けを検討頂ければと思います。