2026.09.22 インフラ

AWS Cloud9は今も使えるか｜新規受付終了後の棚卸しと移行をCLIで進める手順

AWS Cloud9は2024年7月25日に新規顧客への提供を終了しました。新しく作ったAWSアカウントでは起動できず、それ以前から使っているアカウントだけが継続利用できる状態です。困るのは「使い始めたい人」より、むしろ「昔作った環境が残っている人」のほうでした。誰も開いていないIDE環境の裏でEC2とEBSが動き続けている案件は珍しくありません。この記事では、aws cloud9 describe-environmentsで残存環境を全リージョン洗い出し、実体のEC2とEBSを突き合わせ、CloudShellやAWS IDE Toolkits、code-serverへ移したうえで安全に削除するまでを、公式ドキュメントの実値とコマンド付きで整理しました。

まとめ｜AWS Cloud9は新規作成不可・既存環境は期限を切って移す

結論から言えば、これからAWS Cloud9を選ぶ余地はありません。AWS Cloud9のユーザーガイドの冒頭には「AWS Cloud9 is no longer available to new customers」という告知が残り、既存顧客は従来どおり使えると書かれています。新規アカウントで試そうとして起動できなかった場合、設定の誤りではなく提供終了が理由です。

既存環境がある側の判断は「止める」ではなく「期限を切って移す」になります。Cloud9のIDE自体に追加料金はかからず、請求が立つのは裏で動くEC2インスタンスとEBSボリュームです。環境を放置しても画面には何も出ませんが、EBSは停止中でも課金対象として残り続けます。

移行先は用途で分かれました。AWSのコマンドを叩くだけならCloudShell、アプリケーション開発を続けるならローカルのVS CodeとAWS Toolkit、ブラウザIDEという形をどうしても残したいならEC2上のcode-serverです。どれを選ぶかの比較はクラウド開発環境の選び方とCloud9終了後の代替比較にまとめてあります。この記事は、選んだあとに手を動かす側を扱います。

2024年7月25日の新規受付終了でCloud9に起きた変化と既存顧客の扱い

提供終了の影響は、アカウントの作成時期で真っ二つに分かれます。まず事実関係を公式の記載で固めておきます。

新規作成したAWSアカウントでCloud9に到達できない状態

2024年7月25日以降に作成したAWSアカウントでは、マネジメントコンソールにCloud9のメニューが出ません。CLIからaws cloud9 create-environment-ec2を叩いても環境の作成はできない状態です。検索で見つかる日本語の入門記事の多くは、この日付より前に書かれたまま更新されていません。「記事どおりに進めたのにボタンが無い」という詰まり方をしたなら、手順の誤りではないと判断してよい状況です。

なお、サービス自体が停止したわけではない点には注意が必要です。AWS CLIのcloud9コマンドリファレンスには、環境操作・メンバー管理・タグ操作で計13のサブコマンドが現在も掲載されています。APIは生きており、既存顧客の操作経路は残っています。

既存顧客が継続利用できる範囲と公式ドキュメントに残る告知の文面

ユーザーガイドの告知は「Existing customers of AWS Cloud9 can continue to use the service as normal」と書かれています。終了日は明示されていません。つまり既存環境は動くものの、機能追加やドキュメント更新が続く前提では設計できない状態にあります。

この「期限が示されないまま継続」という状態が、実務では一番やっかいでした。明確な終了日があれば移行計画を引けますが、示されないと後回しになります。受託案件で引き継いだアカウントを調べると、退職者が作ったCloud9環境がそのまま残っていた、という話につながります。期限が外から与えられないなら、自分たちで切るしかありません。

Cloud9の環境には、AWSがEC2インスタンスごと作るEC2環境と、自分で用意したサーバーに接続するSSH環境の2種類があります。EC2環境とSSH環境の比較ページのとおり、前者は課金対象のインスタンスがAWS側で作られるため、棚卸しで先に潰すべきはEC2環境です。

CLIで既存のCloud9環境を全リージョン横断で棚卸しする手順

コンソールを1リージョンずつ切り替えて目視する方法は、見落としが出ます。数えるならCLIです。ここからはAWS CLI v2の設定とSSO認証が済んでいる前提で進めます。

describe-environmentsで環境の所有者と種別を列挙する手順

環境の一覧はIDだけが返るため、取得には2段階の操作が必要です。list-environmentsでIDを取り、そのIDをdescribe-environmentsに渡して名前・種別・所有者ARNを展開します。1回のdescribeに渡せるIDは複数まとめられるので、小規模なアカウントなら次の形で足ります。

# 東京リージョンのCloud9環境をIDと属性の対で取り出す
REGION=ap-northeast-1
IDS=$(aws cloud9 list-environments --region $REGION --query 'environmentIds' --output text)
echo "環境数: $(echo $IDS | wc -w)"

aws cloud9 describe-environments \
  --region $REGION \
  --environment-ids $IDS \
  --query 'environments[].{Id:id,Name:name,Type:type,Owner:ownerArn,Status:lifecycle.status}' \
  --output table

出力のTypeがec2なら課金の実体を持つ環境、sshなら接続先は自前サーバーです。OwnerのARNは、その環境を誰の権限で作ったかを示します。退職者のIAMユーザーARNが並んでいたら、その時点で棚卸しの優先度は上がります。

全リージョンを総当たりしてCloud9の取りこぼしを潰すスクリプト

Cloud9の環境は、リージョンごとに独立した構成です。東京だけ見て「無い」と結論づけると、バージニア北部で検証した環境を見逃します。提供リージョンを総当たりして、環境が1件でもあるリージョンだけを表示させます。

# Cloud9が有効な全リージョンを走査し、環境が存在するリージョンだけ出す
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  ids=$(aws cloud9 list-environments --region "$r" \
        --query 'environmentIds' --output text 2>/dev/null)
  if [ -n "$ids" ] && [ "$ids" != "None" ]; then
    echo "== $r =="
    aws cloud9 describe-environments --region "$r" --environment-ids $ids \
      --query 'environments[].[id,name,type]' --output text
  fi
done

エラー出力を捨てているのは、Cloud9が提供されていないリージョンでエンドポイント解決に失敗するためです。捨てずに走らせると、存在しないリージョンのエラーで画面が埋まります。走査には数十秒かかりますが、見落としのコストに比べれば安い時間でした。

棚卸しに必要なIAM権限とAccessDeniedが出たときの切り分け

読み取りだけならcloud9:ListEnvironmentsとcloud9:DescribeEnvironments、EC2側の突き合わせにec2:DescribeInstancesとec2:DescribeVolumesが要ります。ここでAccessDeniedが返るとき、原因は2通りに分かれました。権限そのものが無い場合と、SCPやパーミッションバウンダリで上から止められている場合です。

切り分けはエラーメッセージの本文を読むのが早く、SCPで拒否されていれば「with an explicit deny in a service control policy」が含まれます。自分のポリシーだけ見て首をかしげる前に、メッセージ全文を確認してください。IAMの評価順序そのものはIAMのユーザー・ロール・ポリシーの違いと権限設計で整理しています。

Cloud9環境の実体であるEC2インスタンスと停止設定・課金の確認

Cloud9で請求が立つのはIDEではありません。裏のEC2とEBSです。ここを押さえないと「無料のIDEのはずなのに請求が来る」という誤解のまま放置されます。

環境IDからEC2インスタンスとEBSボリュームを突き合わせる

EC2の一覧を眺めても、どれがCloud9の実体かは名前だけでは判別しづらい並びになります。棚卸しで得た環境IDでタグ値を部分一致検索し、当たらなければaws-cloud9-のプレフィックスまで広げて突き合わせます。環境IDはCloudFormationのEnvironmentEC2リファレンスにある2bc3642873c342e485f7e0c561234567のような32桁の文字列です。

# 環境IDでEC2インスタンスと接続中のEBSを突き合わせる
ENV_ID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=*${ENV_ID}*" \
  --query 'Reservations[].Instances[].{Id:InstanceId,Type:InstanceType,State:State.Name,Vol:BlockDeviceMappings[].Ebs.VolumeId}' \
  --output json

# 当たらない場合はCloud9が付けるプレフィックスまで広げる
aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=aws-cloud9-*" \
  --query 'Reservations[].Instances[].{Id:InstanceId,Name:Tags[?Key==`Name`]|[0].Value,State:State.Name}' \
  --output table

どちらでも該当が0件なら、その環境はSSH環境か、インスタンスが先に手動削除された抜け殻です。Stateがstoppedでも安心はできません。停止中のインスタンスにインスタンス料金はかかりませんが、アタッチされたEBSはEC2のオンデマンド料金ページのとおりストレージとして課金され続けます。インスタンス種別と課金単位の関係はAmazon EC2のインスタンスタイプと料金モデルにまとめています。

automatic-stop-time-minutesの上限20160分と課金の関係

Cloud9のEC2環境には、一定時間使われなければインスタンスを自動停止する設定があります。create-environment-ec2のリファレンスによると、--automatic-stop-time-minutesに指定できるのは0から20160分、日数にして14日までです。

ここに落とし穴があります。作成時に長い値を入れた環境は、2週間近くアイドルのまま起動し続ける設定になっている可能性があります。棚卸しで見つけたインスタンスがrunningのまま放置されていたなら、まずこの値を疑ってください。同じリファレンスには--connection-typeの既定がCONNECT_SSHであること、--image-idにresolve:ssm:/aws/service/cloud9/amis/amazonlinux-2023-x86_64のようなSSMパス形式を渡せることも記載されています。

Cloud9自体は無課金でEC2とEBSだけが請求される構造

請求書に「Cloud9」という行が立たないため、コストの追跡は間接的になります。サービス別の内訳ではEC2とEBSに合算されてしまうので、環境IDのタグでフィルタするか、インスタンス単位で追う必要がありました。

実務では、棚卸しで得たインスタンスIDを控えたうえでコスト側を確認する順序が確実です。Cost Explorerでのコスト可視化と分析の手順でリソース単位の内訳を出せば、止め忘れの環境がいくら食っていたかが数字で出ます。撤収の稟議を通すには、この数字があるほうが早く進みました。

移行先4案の採用条件とCloudShell・IDE Toolkitsの実際の制約

AWSが公式に示した移行先は2つですが、実務ではもう2つ候補が要ります。それぞれ向く作業がはっきり分かれるので、条件で振り分けます。

CloudShellの1vCPU・2GiB・永続1GBという上限と向く作業

AWS公式ブログの移行案内は、移行先としてAWS IDE ToolkitsとAWS CloudShellの2つを挙げています。CloudShellは追加料金なしで、コンソールから即座に開けます。

ただしスペックは小さめです。CloudShellのコンピューティング環境の仕様によると、割り当ては1 vCPUと2 GiB RAM、永続ストレージはリージョンあたり1 GBです。ベースはAmazon Linux 2023で、git・make・pip・vim・Docker・kubectlなどがプリインストールされています。

さらにCloudShellのユーザーガイドには、VPC環境では永続ストレージが無く、20〜30分の無操作でタイムアウトすると明記されています。`$HOME`の外に置いたファイルはセッション終了時に消えます。CLI操作やスクリプトの実行には十分ですが、ビルドを回すアプリケーション開発の常用環境としては採用を見送る判断が妥当です。

移行先	費用	状態の保持	採用する条件
AWS CloudShell	追加料金なし	$HOMEに1GB（VPC環境は保持なし）	CLI操作・運用作業が中心
VS Code + AWS Toolkit	無料（ローカル資源）	ローカルディスク	端末にIDEを入れてよい組織
SageMaker Code Editor	インスタンス課金	EFSまたはEBS	機械学習・データ処理が主目的
EC2上のcode-server	EC2+EBS課金	EBS	ブラウザIDEの形を残す必要がある

表の並びは、検討する順序でもあります。上から試して要件を満たせなかったものだけ下に降りるほうが、運用の手間は小さく収まりました。

VS Code＋AWS Toolkitをローカルに置くときの前提条件

AWS IDE Toolkitsは、VS CodeやJetBrains製IDEにAWS連携を足す拡張です。AWS Toolkit for VS Codeのユーザーガイドのとおり、マーケットプレースから拡張を入れて認証情報を設定すれば、Lambdaのデプロイやログ参照をIDE内から行えます。

前提になるのは「開発端末にIDEとソースを置いてよいか」です。受託や金融系の案件では、ソースコードの端末保存を禁じる規程があり、Cloud9をブラウザIDEとして採っていた理由がそこにあった、というケースがあります。その場合はローカル案が最初から落ちるので、下の2案に進みます。

SageMaker Code Editorとcode-serverの使い分けの境界

SageMaker StudioのCode Editorは、Code-OSSベースのIDEをマネージドで提供します。ブラウザで開ける点はCloud9に近く、AWS側が環境を管理してくれる点も安心できる要素です。一方でSageMaker Studioのドメイン設定が前提となり、Webアプリケーション開発だけのためにStudioを立てるのは構成として重くなります。

境界はこう引きました。機械学習やデータ処理が主目的ならSageMaker Code Editor、Webシステムの開発環境をブラウザに残したいだけならEC2上のcode-serverです。判断基準を並べるだけでは決まらないので、後者の構築手順を次章で具体化します。

code-serverでブラウザIDEを自前構築するEC2構成と設定例

code-serverは、VS CodeをサーバーサイドでホストしブラウザからアクセスさせるOSSです。Cloud9に一番近い使用感を、自分の管理下で再現できます。

EC2にcode-serverを入れるインストールコマンドと必要スペック

code-serverのGitHubリポジトリには、要件としてWebSocketが通るLinuxマシン・1 GB RAM・2 vCPUが挙げられ、ライセンスはMITと明記されています。インストールは公式のスクリプトを叩くだけで終わります。

# Amazon Linux 2023 / Ubuntu 共通のインストールとサービス起動
curl -fsSL https://code-server.dev/install.sh | sh

# 起動と自動起動の設定（ec2-userの場合）
sudo systemctl enable --now code-server@ec2-user

# 初期パスワードは設定ファイルに生成される
cat ~/.config/code-server/config.yaml

公式が示す1 GB RAM・2 vCPUはあくまで下限であり、拡張機能や言語サーバーを載せた常用環境ではt3.small以上に余裕を見ておく設計になります。Cloud9で使っていたインスタンスタイプが分かっているなら、それと同等から始めるのが最短です。稼働後にCloudWatchのメモリ・CPUメトリクスを見て、余っていれば1段落とす順序で詰めます。

SSHポートフォワードで外部公開せずブラウザから接続する設定

設定ファイルの既定では127.0.0.1:8080で待ち受けます。ここをセキュリティグループで全開にしてインターネットへ晒す構成は採りません。パスワード1本でソースコードが読める状態になるためです。手元からSSHトンネルを張り、ローカルのlocalhost経由で開きます。

# 手元の8080をEC2上のcode-serverへ転送する（Session Manager経由も可）
ssh -N -L 8080:127.0.0.1:8080 ec2-user@<インスタンスのIP>

# ブラウザで http://127.0.0.1:8080 を開き、config.yamlのpasswordで認証する

踏み台を置きたくない場合は、SSM Session Managerのポートフォワーディングに置き換えると、インバウンド22番を開けずに同じことができます。どちらを採るにしても、code-serverのポートをパブリックに出さない方針は変えないでください。Cloud9はAWS側が認証を担保していましたが、自前運用では担保するのは自分たちです。

移行後にCloud9環境を削除する順序と残骸を残さない確認項目

撤収で失敗するのは、消す順番と消し残しです。公式ブログも移行後のEC2インスタンス削除を明示的に促しています。ここは言い切ります。移行先で1度も作業していない段階でCloud9環境を消してはいけません。

移行完了を確認してからdelete-environmentを叩く順序

環境内に置いたファイルは、環境を削除すると同時に消えます。先にリポジトリへpushされていない変更が残っていないかを確認し、移行先で実際にビルドやデプロイが1周通ることを見てから削除に進みます。順序は次のとおりです。

Cloud9環境内の未コミット差分をGitへ退避する
移行先で同じ手順を実行し、ビルドとデプロイが通ることを確認する
Cloud9環境のEC2インスタンスを停止し、数日から2週間ほど様子を見る
差し支えがなければaws cloud9 delete-environmentで環境を削除する

手順3を挟むのは、忘れていた依存が出てくるためです。cronで動いていたバッチ、環境内にだけ置かれた認証情報、ローカルのDockerイメージ。停止した状態でしばらく放置すると、困る人がいれば声が上がります。いきなり削除すると、そのフィードバックを受け取る機会ごと消えます。

環境を消してもEBSスナップショットとIAMロールが残る場合

EC2環境を削除すると、接続されていたEC2インスタンスも終了します。ただし手動で取得したEBSスナップショット、Cloud9用に作ったIAMロールやインスタンスプロファイル、Elastic IP、セキュリティグループは対象外です。削除後に次の確認を回してください。

環境IDを含む名前のEBSスナップショットが残っていないか
Cloud9用に作成したIAMロールとインスタンスプロファイルが未使用で残っていないか
どのENIにも紐づかないElastic IPが残っていないか（未関連付けのIPは課金対象）
Cloud9環境向けに開けたセキュリティグループのインバウンド規則が残っていないか

この4点のうち、請求に直結するのはスナップショットと未関連付けのElastic IPです。顧客アカウントの撤収を請け負うとき、削除した「つもり」で残るのはたいていこの2つでした。撤収作業そのものを外部に任せたい場合は、インフラ構築（AWS・Google Cloud・Azure）の相談先として一創でも対応しています。

よくある質問

AWS Cloud9の提供終了と移行について、検索で多く見られる質問に答えます。

AWS Cloud9は完全に終了したのですか？

サービスが停止したわけではありません。2024年7月25日に新規顧客への提供が終わり、それ以前からの既存顧客は従来どおり利用できる状態です。ユーザーガイドにも「既存顧客は通常どおりサービスを使い続けられる」と記載が残っています。ただしサービス終了日は示されていないため、いつまで使えるかを前提にした設計はできません。既存環境がある場合は、自分たちで移行期限を決めて進めるのが現実的な対応になります。

新しく作ったAWSアカウントでCloud9を使う方法はありますか？

ありません。2024年7月25日以降に作成したアカウントでは、コンソールのメニューにも表示されず、CLIからの環境作成も通りません。回避策を探すより、CloudShellかローカルのVS Code＋AWS Toolkitへ切り替えるほうが早く片が付きます。AWSのコマンドを叩くだけならCloudShellがブラウザから即座に使え、追加料金もかかりません。

Cloud9の料金はいくらかかっていたのですか？

Cloud9のIDE部分に追加料金はなく、請求が立つのは裏で動くEC2インスタンスとEBSボリュームです。そのため請求書に「Cloud9」という項目は現れず、EC2とEBSに合算されます。インスタンスを停止していてもEBSのストレージ料金は発生し続けるため、使っていない環境を止めただけでは費用はゼロになりません。金額を確定させたい場合は、環境IDからインスタンスを特定し、Cost Explorerでリソース単位の内訳を確認してください。

Cloud9環境を削除するとファイルはどうなりますか？

環境内に保存していたファイルは、環境の削除と同時に失われます。EC2環境の場合は接続されていたEC2インスタンスも終了します。削除の前に、未コミットの変更をGitリポジトリへ退避し、環境内にだけ置いていた認証情報や設定ファイルを別の場所へ移してください。インスタンスをいったん停止して数日置き、困る人がいないかを確かめてから削除に進むと、取り返しのつかない消し方を避けられます。

CloudShellはCloud9の代わりになりますか？

作業の種類によります。CloudShellは1 vCPU・2 GiB RAM・永続ストレージ1 GBという割り当てで、無操作が続くとセッションがタイムアウトします。AWS CLIでの運用作業やスクリプト実行には十分ですが、ビルドを繰り返すアプリケーション開発の常用環境としては手狭です。IDEとしての使い勝手を残したい場合は、ローカルのVS CodeとAWS Toolkit、またはEC2上のcode-serverを検討してください。