AWS Cloud9 移行ガイド｜IDE Toolkits/CloudShell選定

1. この記事について

1-1. 本記事のゴール

本記事を読み終えると、新規受付終了(2024-07-25)したAWS Cloud9の現況を正確に理解したうえで、AWS公式が推奨するIDE Toolkits(VS Code/JetBrains等のAWS Toolkit拡張)とCloudShell(マネジメントコンソール内蔵のブラウザシェル)のどちらへ移行すべきかを、自分の開発スタイルに沿って判断できるようになります。

読了後にできること:

• Cloud9が新規受付終了・既存顧客は継続利用可能であるという現況を、公式一次情報から正確に説明できる
• 本格的なコード編集・デバッグ・ローカルIDE中心の開発スタイルはIDE Toolkitsへ、ブラウザ完結の軽量なCLI操作・ハンズオン中心の使い方はCloudShellへ、という選定ロジックを理解できる
• Cloud9の主要機能(ブラウザIDE・ターミナル・デバッガ・環境共有・EC2連携・プレビュー)が、移行先の何に対応するかを機能マッピング表で把握できる
• 移行時に起きやすい詰まりポイント・アンチパターンを事前に回避できる

本記事の構成:

各章は移行先ごとに独立して参照できるよう構成しています。移行先がまだ決まっていない場合は§2から、すでに決まっている場合は該当する§3・§4から読み進めることをおすすめします。

本記事の前提知識:

本記事は、以下を前提として解説します。

• AWS IAM(ロール・ポリシー)の基本的な設定方法
• Cloud9でのブラウザIDE・ターミナル操作の基本的な利用経験
• 現在Cloud9で使っている機能(ブラウザIDE本体・ターミナル・デバッガ・環境共有・EC2連携・プレビュー機能)の把握

上記の前提知識が十分でない場合も、§2の内容自体は前提知識なしで読み進められます。実際の移行手順(§3・§4)へ着手する前に、必要に応じて現在のCloud9環境で使っている機能を棚卸ししておくことをおすすめします。

1-2. 読者像

想定する読者は、大きく2タイプです。

既存Cloud9利用者が本記事で解決したい典型的な悩み:

• 新規受付終了という状態が、既存プロジェクトの利用継続にどう影響するのか正確に理解したい
• IDE ToolkitsとCloudShellのどちらに移行すべきか、自分の開発スタイルに沿った判断基準がない
• Cloud9固有の機能(ターミナル・デバッガ・環境共有・EC2連携・プレビュー)が、移行先でどう表現されるのか対応関係が分からない

新規開発環境の検討者が本記事で解決したい典型的な悩み:

• ブラウザ完結型の開発環境・ハンズオン環境の基盤として何を選定候補に入れるべきか、Cloud9は選定対象から外すべきなのか判断したい
• IDE Toolkits・CloudShellという候補それぞれの向き不向きを比較したい

自組織がどちらの読者タイプに近いか判断する目安:

すでにCloud9でブラウザIDE・ハンズオン環境を運用している場合は「既存Cloud9利用者」、これから開発環境・研修環境を新規に選定する場合は「新規開発環境の検討者」に該当します。どちらの読者タイプであっても、§2で扱うCloud9の現況と移行先2択の選定軸は共通して役立つ内容です。

いずれの読者も、移行先であるIDE Toolkits・CloudShellそのものの基礎的な使い方(拡張機能のインストール手順・コンソール操作の基本)は既知、またはこの後に紹介する情報で補える前提とし、本記事は「Cloud9からの移行」という論点に絞って解説します。

本記事が想定していない読者:

• AI補完エージェントとしてのAmazon Q Developerの使い方そのものを学びたい方(既存記事「AWS Amazon Q Developer 本番運用 Vol1」が適しています)
• IDE Toolkits・CloudShellの基礎的な操作そのものを一から学びたい方

既存記事「AWS Amazon Q Developer 本番運用 Vol1」ではVS Code/JetBrains統合を扱っていますが、これはAI補完エージェントとしてのQ DeveloperのIDE統合が主題であり、Cloud9からの移行・AWS Toolkit(リソース管理拡張)・CloudShellへの言及はありません。本記事は「Cloud9という開発環境そのものの移行」に絞る点で、その既存記事とは主題が異なります。両者は開発ツールという領域では隣接していますが、扱う論点は独立しているため、必要に応じて両方参照することをおすすめします。

1-3. なぜ今これを書くか

AWS Cloud9は、公式ドキュメント(cloud9 additional-info、取得日2026-07-18)において以下のように明記されています。

AWS Cloud9 is no longer available to new customers. Existing customers of AWS Cloud9 can continue to use the service as normal.

この記述から、以下の2点が確認できます(取得日2026-07-18時点、公式一次情報)。

この状況を受けて、AWS公式は移行ブログ(how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell、英語・日本語版とも公開)を出し、IDE ToolkitsとCloudShellへの移行を案内しています。AWS自身が移行を推奨している以上、Cloud9を使い続けているプロジェクトは移行計画を検討する時期に来ています。

出典: AWS Cloud9の概要ページ(additional-info)、およびAWS公式移行ブログ(取得日2026-07-18)。両ページとも本記事執筆時点で内容の変化はありません。

本記事の差別化ポイント:

日本語圏にはサードパーティ製の代替ブラウザIDE(Codespaces/Gitpod/code-server等)を紹介する記事は多く存在しますが、本記事はそれらとは狙いが異なります。

• AWS公式が推奨する2択(IDE Toolkits・CloudShell)への収束型ガイドであり、サードパーティ代替の発散的な比較・紹介は行わない
• Cloud9固有機能(ブラウザIDE本体・ターミナル・デバッガ・環境共有・EC2連携・プレビュー)が移行先の何に対応するかの機能マッピングを主軸に据える
• 個人のハンズオン用ブラウザIDE選びではなく、企業・実務でのプロジェクト移行という視点で選定基準・移行手順・アンチパターンまでを整理する

サードパーティ製の代替に触れる場合も、本記事では「AWS公式推奨2択との位置づけの違い」を一言添える程度に留め、代替ツール自体の機能比較には踏み込みません。この収束型の構成が、発散的な代替ツール紹介記事との最大の違いです。

なお、AWS公式の移行ブログはIDE Toolkits/CloudShellへの移行を案内する内容ですが、Cloud9固有機能から移行先への体系的な対応マッピングと、用途別の選定フローまでを日本語でまとめた記事は手薄です。本記事は§2でCloud9の現況把握から移行先の選定軸を整理し、§3・§4で移行先ごとの具体的な手順、§5でCloud9機能の総合対応マッピング、§6でチェックリストによる仕上げまで、一連の流れで移行を完走できるように構成しています。

よくある質問:

• Q. 既存のCloud9環境は今すぐ使えなくなるのか? A. いいえ。既存顧客は引き続き通常どおり利用できます。ただし完全なシャットダウン日は現時点で告知されていないため、いつまでも使い続けられる保証があるわけでもありません。
• Q. サードパーティ製の代替ブラウザIDEは検討しなくてよいのか? A. 本記事はAWS公式が推奨するIDE Toolkits/CloudShellの2択に絞って解説します。サードパーティ製の代替は、AWS環境との統合度・サポート体制の観点でAWS公式移行先とは位置づけが異なるため、本記事のスコープ外としています。
• Q. IDE ToolkitsとCloudShellは併用できるか? A. できます。2-3で扱うとおり、ローカルでのコード編集はIDE Toolkits、ちょっとしたCLI操作やハンズオンはCloudShell、という使い分けも実務上は有効な選択肢です。
• Q. 移行を後回しにしても実務上気づきにくいのではないか? A. 既存顧客が通常どおり利用できる状態は静かに続くため、移行を先送りしても直後に不具合として顕在化するとは限りません。しかし完全シャットダウン日が予告なく確定した場合、その時点から移行計画を立て始めるのでは対応が後手に回ります。現在の利用機能の棚卸しと移行先の判断だけでも早めに済ませておくことをおすすめします。

IDE統合によるAI補完エージェント活用はこちら

2. 前提・Cloud9 の現況・移行判断の枠組み

2-1. AWS Cloud9 の現況(取得日2026-07-18)

AWS Cloud9は、公式ドキュメント(cloud9 additional-info、取得日2026-07-18)において以下のように明記されています。

AWS Cloud9 is no longer available to new customers. Existing customers of AWS Cloud9 can continue to use the service as normal.

この記述から、以下の3点が確認できます(取得日2026-07-18時点、公式一次情報)。

1. 新規顧客への提供は終了している(2024-07-25)。これから新規にCloud9環境を作成できません。
2. 既存顧客は通常どおり利用を継続できる。今すぐ既存の環境が使えなくなるわけではありません。
3. 完全なシャットダウン日は未告知。いつまで既存顧客が利用できるかは、本記事執筆時点(取得日2026-07-18)で公式にアナウンスされていません。

よくある誤解と正しい理解:

既存のCloud9環境が動いているからといって移行を先送りし続けると、完全シャットダウン日が確定してから慌てて移行計画を立てることになりかねません。この状態を正確に理解したうえで、次の2-2・2-3で移行先の選定に進みます。

「既存顧客は通常どおり利用を継続できる」という記述の実務上の意味も、あわせて確認しておきます。ここでいう「通常どおり」とは、既存のCloud9環境をそのまま起動・利用でき、これまでどおりコード編集・ターミナル操作を行えるという意味です。一方で、新規受付終了となったサービスでは、以下のような点は今後見込みにくくなる傾向があります。

• 新機能・UIの追加や改善
• ドキュメント・サポート体制の拡充
• 障害発生時の対応優先度

つまり「今すぐ使えなくなる」リスクではなく、「今後の改善・サポートが手薄になっていく」リスクが本質です。既存環境がシンプルで安定稼働している場合、当面の利用継続自体に支障はありません。しかし新しい要件が出てきたときにCloud9側での対応が期待できない以上、その時点で初めて移行を検討するのでは後手に回りやすい、という点が実務上の要点です。

移行の検討を先送りした場合に起きやすいこと:

• 「まだ動いているから」と先送りするうちに、移行先の選定基準を整理する余裕がなくなる
• 完全シャットダウン日が予告なく確定した場合、限られた期間で複数環境の移行を一斉に進める必要が生じる
• IDE Toolkits・CloudShellのどちらが自分の開発スタイルに合うか比較しないまま1つに決めてしまい、後から他の選択肢の方が適していたと気づく

これらはいずれも、移行先の選定基準を事前に押さえておけば避けられる問題です。本記事では§2〜§6でこれらを順に解消していきます。

よくある質問:

• Q. 猶予期間中は移行を急がなくてよいか? A. 緊急性は運用要件次第ですが、様子見の期間として使うのはおすすめできません。完全シャットダウン日が未告知である以上、猶予期間は「移行先の選定・計画・実行を進めるための時間」として使うのが実務的です。
• Q. 一部のCloud9環境だけ移行を後回しにできるか? A. 技術的には可能です。ただし新規受付終了という状態は全環境に共通するため、後回しにした環境も遅かれ早かれ移行が必要になります。優先度をつける場合も、全環境の移行完了時期をまず見積もっておくことをおすすめします。
• Q. 移行先は必ず1つに決めなければならないか? A. いいえ。2-3で扱うとおり、開発スタイルによっては複数の移行先を併用する構成も選択肢になります。
• Q. Cloud9からエクスポートしておくべきデータはあるか? A. あります。環境内に置いているコード資産(未コミットの変更を含む)・カスタム設定・環境変数等は、移行先へ引き継ぐ前に必ずバックアップまたはGitリポジトリへのコミットを済ませておく必要があります。詳細な手順は§3・§4で扱います。

出典: AWS Cloud9の概要ページ(additional-info)、およびAWS公式移行ブログ(取得日2026-07-18)。両ページとも本記事執筆時点で内容の変化はありません。

社内展開時のポイント:

社内の関係者にこの状況を説明する際は、「サービスが終了する」という表現よりも「新規受付終了・完全シャットダウン日は未告知だが、既存利用は継続できる状態」という表現の方が正確です。「終了」という言葉だけが独り歩きすると、既存環境の緊急停止を連想させ、必要以上に慌てた対応を招きかねません。逆に「まだ動いているから大丈夫」という理解のまま止まってしまうと、予告なく完全終了が確定した際に対応が後手に回ります。この2つの誤解の中間にある正確な状態を共有することが、移行計画をスムーズに進めるための第一歩です。

2-2. 移行先2択の概観(AWS公式推奨)

AWS公式の移行ブログは、Cloud9の移行先としてAWS IDE ToolkitsとAWS CloudShellの2つを案内しています。それぞれの特徴を整理します。

2つの移行先とも健全に提供されており、本記事執筆時点(取得日2026-07-18)でEOLの兆候はありません。

Cloud9が担っていた「ブラウザから開発・AWSリソース操作ができる」という役割は、この2つの移行先のいずれかに引き継がれますが、どちらが最適かは開発スタイルによって変わります。

AWS IDE Toolkitsは、VS Code・JetBrains(IntelliJ/PyCharm等)といった手元のIDEへ、AWSリソースの探索・管理・デプロイ・ローカルデバッグの機能をオープンソース拡張として統合するツールです。IDEの拡張機能マーケットプレースからインストールし、AWS認証情報を設定するだけで利用を開始できます。Cloud9で組んでいた「ブラウザIDEでのコード編集」「AWSリソースへのデプロイ」「Lambda関数のローカルデバッグ」のような本格的な開発作業は、IDE Toolkitsの得意領域と重なります。

AWS CloudShellは、AWSマネジメントコンソールに内蔵されたブラウザベースのシェル環境です。AWS CLIがプリインストールかつ認証済みの状態で提供されるため、ログインするだけですぐにコマンド操作を始められます。Cloud9が担っていた「ブラウザ完結でのターミナル操作」「ちょっとしたスクリプト実行」「ハンズオン・研修環境」のような軽量な使い方は、CloudShellの得意領域と重なります。利用にあたって追加料金は発生しません。

コスト構造の違いも押さえておくと、移行判断の材料になります。Cloud9自体はEC2連携型の環境であればEC2インスタンス・EBSボリュームの利用料が発生していましたが、IDE Toolkitsは拡張機能自体が無料で、コストが発生するとすれば接続先のAWSリソース(デプロイ先のLambda・EC2等)の利用料のみです。CloudShellは環境自体が無料で提供されており、Cloud9で発生していたインスタンス・ストレージ課金が実質的になくなる点も、移行のメリットとして挙げられます。

サポート・ドキュメントの充実度についても、新規受付終了となったCloud9と比較して、IDE Toolkits・CloudShellはいずれも現役でアップデートが継続されているサービスであるため、公式ドキュメント・コミュニティ双方の情報が引き続き更新されています。この点も、長期的な運用を見据えるうえでは移行のメリットに数えられます。

なお、サードパーティ製の代替ブラウザIDE(Codespaces/Gitpod/code-server等)も存在しますが、本記事はAWS公式が推奨するこの2択への移行に焦点を絞ります。サードパーティ代替はAWS環境との統合度・サポート体制の観点でAWS公式移行先とは位置づけが異なるため、本記事では深追いしません。

移行に伴う機能的な役割の変化(詳細な対応表は§5):

Cloud9の各機能が担っていた役割は、移行先ごとに異なる形で引き継がれます。ここでは全体像として、機能がどちらの移行先に対応するかを大まかに押さえておきます。

この対応関係はあくまで機能レベルの大枠であり、実際の設定項目レベルでの詳細なマッピングと移行手順は、移行先ごとに§3・§4で個別に扱います。ここでは「Cloud9の各機能が、移行先では何にあたるのか」という見取り図を先に持っておくことで、2-3の判断軸を検討する際の材料にしてください。

上記の表からも分かるとおり、IDE Toolkitsはコード編集・デバッグ・EC2連携までCloud9の主要機能を広くカバーできる一方、CloudShellはターミナル操作・EC2へのSSH接続に用途が絞られます。環境共有機能については、どちらの移行先にもCloud9と同じ形の代替機能は存在しないため、移行時に別途の運用ルールを検討する必要がある点は共通の注意点です。

2-3. 移行先選定の判断軸

IDE ToolkitsとCloudShellのどちらを選ぶべきかは、現在Cloud9で行っている開発スタイルによって決まります。以下の判断フローに沿って、自分の使い方を確認してください。

移行先選定の判断フロー:

判断にあたっては、以下のCloud9固有機能の要否も分岐要素として確認してください。

• EC2連携開発の要否: Cloud9はEC2インスタンスに直接接続してブラウザから開発する構成が一般的でした。この使い方を継続したい場合、IDE Toolkitsをローカル/リモートIDEからEC2インスタンスへのリモート接続と組み合わせる構成が代替になります。
• 環境共有機能の要否: Cloud9には開発環境をチームメンバーと共有する機能がありました。IDE Toolkits・CloudShellのいずれにもCloud9と同じ形の「環境共有」機能は無いため、Gitリポジトリ経由でのコード共有や、Live Share系の拡張機能など、代替手段の検討が必要です。
• プレビュー機能の要否: Cloud9にはブラウザ内でアプリケーションのプレビューを表示する機能がありました。この用途はローカル開発サーバー+ブラウザでの確認、またはCloudShellのポートフォワーディング的な使い方で代替します。

典型的な判断シナリオ:

具体的な使い方の例に沿って、判断の流れを確認します。

• シナリオA(本格的なアプリケーション開発): Cloud9でLambda関数・コンテナアプリケーションのコードを書き、デバッグしながらAWSリソースへデプロイしている場合。開発の中心がコード編集・デバッグであるため、IDE Toolkitsへの移行が第一候補です。手元のIDEに慣れているチームであれば、移行後の生産性はむしろ向上することが多いです。
• シナリオB(ハンズオン・研修環境): 研修やワークショップの参加者に、追加インストール不要ですぐ使えるCLI環境を提供したい場合。CloudShellへの移行が第一候補です。ブラウザとAWSアカウントさえあればすぐに利用を開始できるため、Cloud9のハンズオン用途をそのまま代替できます。
• シナリオC(EC2インスタンスへの接続開発): EC2インスタンスにCloud9を紐づけ、ブラウザからそのインスタンス上のコードを編集していた場合。IDE ToolkitsをリモートSSH接続と組み合わせる構成、またはCloudShellから対象インスタンスへSSH接続してCLI操作する構成のいずれかを、開発の中心がコード編集かCLI操作かで選び分けます。

これらの判断軸を組み合わせても移行先が1つに絞りきれない場合、複数の移行先を併用する構成(例: 本格的な開発はIDE Toolkits、ちょっとした確認作業はCloudShell)も選択肢になります。実際には1人の開発者・1つのチームの中に複数の使い方が混在するケースも多く、その場合は用途ごとに移行先を使い分ける運用が現実的です。

自社のCloud9環境棚卸し手順:

判断軸を検討する前に、まず自社で運用中のCloud9環境を漏れなく洗い出しておく必要があります。Cloud9コンソールの環境一覧画面、またはAWS CLIのaws cloud9 list-environmentsで全環境IDを取得し、各環境についてaws cloud9 describe-environmentsで環境タイプ(EC2連携/SSH接続)や設定を確認します。この棚卸しを通じて、各環境が「本格的なコード編集・デバッグ中心」「ブラウザ完結のCLI操作・ハンズオン中心」のどちらに該当するかを分類し、2-3の判断フローに当てはめてください。

棚卸しの際は、以下の観点も併せて記録しておくと、後続の移行手順(§3・§4)での見積もりがしやすくなります。

• 各環境の利用頻度(日常的な開発利用か、研修等のスポット利用か)
• 各環境で使用しているランタイム・言語(Node.js/Python/Java等)
• EC2連携の有無・紐づいているインスタンスタイプ
• 環境共有機能を実際に使っているメンバー数

この棚卸し結果は、そのまま2-3のセルフチェックリストの回答材料になります。

移行工数の目安(既存の開発環境設定による違い):

移行先を決めたあと、実際にどの程度の工数がかかるかは、既存の開発環境設定によって大きく変わります。目安として、2つの移行先それぞれについて工数が変動する要因を整理します。

工数の目安を把握しておくことで、移行先選定と同時に大まかなスケジュール感を関係者と共有しやすくなります。正確な工数見積もりは、実際の移行手順(§3・§4)を確認したうえで行うことをおすすめします。複数のCloud9環境を運用している場合は、棚卸し結果をもとに影響範囲の小さい環境から先に移行し、手順や詰まりポイントを確立したうえで残りの環境へ展開していく進め方が実務的です。

判断に迷う場合のフォールバック:

上記の判断軸・チェックリストを確認してもなお1つに絞りきれない場合は、以下の優先順位で検討することをおすすめします。

1. 現在の作業内容の比重で決める: コード編集・デバッグに費やす時間の方が長いならIDE Toolkits、CLI操作・確認作業に費やす時間の方が長いならCloudShell、というように実際の作業時間の比重で判断します。
2. チームのスキルセット・使用IDEを優先する: すでにVS Code・JetBrainsを使い慣れているチームであれば、IDE Toolkitsへの移行は学習コストが小さく済みます。逆にIDEへのこだわりがなく、AWS CLI操作が中心のチームであればCloudShellの方がシンプルです。
3. 小規模な検証から始める: 判断がつかない場合、まず両方を試験的に使ってみたうえで、チーム全体の移行先を決める進め方も有効です。IDE Toolkits・CloudShellはいずれも無料で試せるため、判断に迷った段階でまず両方を触ってみることをおすすめします。

チームのスキルセットも判断軸に加える:

技術的な適合度だけでなく、実際に移行後の開発を担うチームのスキルセットも判断軸として重要です。VS Code・JetBrainsの利用経験が豊富なチームであればIDE Toolkitsへの移行後もスムーズに開発を続けられますが、これらのIDEに不慣れなチームがIDE Toolkitsを選ぶ場合は、移行後の学習コストを見込んでおく必要があります。同様に、CloudShellの運用にはAWS CLI操作への理解が求められます。技術的な適合度とチームのスキルセットが一致しない場合、移行先を変更するか、移行後の学習期間を計画に織り込むかのいずれかを検討してください。

判断のためのセルフチェックリスト:

このチェックリストを一通り確認し終えたら、移行先が定まっているはずです。まだ判断に迷う項目が残っている場合は、該当する2-3の判断軸や前述のフォールバックの優先順位に戻って確認してください。

§2のまとめ:

ここまでで、Cloud9の現況(新規受付終了・既存顧客の継続利用は可能・完全シャットダウン日未告知)、移行先2択の概観、そして移行先を選ぶための判断軸を整理しました。

自分の開発スタイルがどちらの移行先に近いか判断できたら、該当する§3(IDE Toolkits)・§4(CloudShell)へ進んでください。§5では、ここで整理した機能対応の詳細版と、移行後の検証項目・チェックリストをまとめて確認できます。

両方の移行先を併用する構成を選んだ場合も、§3・§4はそれぞれ独立して読み進められるよう構成しているため、必要な章から個別に参照して問題ありません。移行先の判断に迷った場合は、いったん§3・§4を両方軽く読んでから、あらためて2-3の判断軸に戻って検討するという進め方も有効です。

3. 移行先① — AWS IDE Toolkits(VS Code / JetBrains)への移行

3-1. IDE Toolkits が適する用途

2-3の判断軸で「本格的なコード編集・デバッグ・ローカルIDE中心の開発」に該当した場合、移行先はAWS IDE Toolkitsが第一候補です。IDE Toolkitsは、VS Code・JetBrains(IntelliJ/PyCharm等)といった手元のIDEへ、AWSリソースの探索・管理・デプロイ・ローカルデバッグの機能をオープンソース拡張として統合するツールです。

以下のような使い方をCloud9でしていた場合、IDE Toolkitsへの移行が特に効果的です。

• Lambda関数・コンテナアプリケーションのコードを日常的に編集し、デバッグしながらAWSリソースへデプロイしている
• AWS SAM・CloudFormationを使ったサーバーレスアプリケーションを開発している
• IDEの補完・リファクタリング機能をフル活用したい(Cloud9のブラウザIDEよりも高機能な編集体験を求めている)

逆に、コード編集をほとんど行わず、CLI操作の確認や短時間のハンズオンが中心だった場合は、IDE Toolkitsよりも§4で扱うCloudShellの方が移行コストは小さく済みます。

3-2. Cloud9機能 → AWS Toolkit拡張の対応

Cloud9で使っていた主要機能が、AWS Toolkit(VS Code/JetBrains拡張)の何に対応するかを整理します。

Cloud9のデバッガはAWS SAM CLIと連携したLambda関数のローカルデバッグにおおむね対応しますが、Cloud9のように「ブラウザだけで完結する」体験ではなく、ローカル(またはリモート接続先)のIDE上での操作に変わる点が最大の違いです。環境共有機能については、IDE Toolkits側に直接の代替機能が存在しないため、移行時にはGitリポジトリでのコード共有運用に切り替える必要があります。

3-3. セットアップ手順(概略)

AWS公式の移行ブログでは、IDE Toolkitsのセットアップは「拡張機能をインストールし、AWS認証情報で認証するだけ」とシンプルに案内されています。実際の手順は以下のとおりです。

1. IDEの準備: VS Codeの場合、AWS Toolkit for VS Codeの動作要件であるVS Code 1.73.0以降であることを確認します(取得日2026-07-18時点の公式ドキュメントに基づく)。JetBrains系(IntelliJ/PyCharm等)の場合も同様に、対応バージョンを事前に確認します。
2. AWS Toolkit拡張のインストール: VS CodeのExtension Marketplace、またはJetBrainsのPlugin Marketplaceから「AWS Toolkit」を検索してインストールします。
3. AWS認証情報の設定: IDE上でAWSアカウントへサインインします。IAM Identity Center(旧AWS SSO)経由の認証、あるいはIAMユーザーのアクセスキーによる認証情報プロファイルのいずれかを設定します。Cloud9でIAMロールを直接アタッチして利用していた場合と異なり、IDE Toolkitsではローカル(接続先を含む)の認証情報プロファイルを明示的に設定する必要がある点に注意してください。
4. AWS Explorerでの疎通確認: サイドバーのAWS Explorerに、設定したリージョンのリソース(Lambda/S3/CloudFormation等)が表示されることを確認します。
5. (EC2連携を使っていた場合)EC2インスタンスへの接続設定: AWS ExplorerのEC2インスタンス一覧から対象インスタンスを右クリックし、「Connect VS Code to EC2 instance」を選択します。この機能はSession Manager(SSM)経由で接続するため、対象EC2インスタンスのインスタンスプロファイルにssmmessages:CreateControlChannel・ssmmessages:CreateDataChannel・ssmmessages:OpenControlChannel・ssmmessages:OpenDataChannel・ssm:DescribeAssociation・ssm:ListAssociations・ssm:UpdateInstanceInformationのIAM権限が必要です。フルリモート開発(ターミナル接続ではなくVS Code自体をリモート接続する場合)にはローカル環境にSSHクライアントのインストールも必要になります。
6. (SAMアプリケーションを使っていた場合)SAM CLIの導入: ローカルデバッグを行う場合はAWS SAM CLIをローカルにインストールし、AWS Toolkitのデバッグ機能から呼び出せる状態にします。

出典: AWS公式移行ブログ、AWS Toolkit for VS Code公式ドキュメント(Installing)、AWS Toolkit for VS Code公式ドキュメント(EC2連携)(いずれも取得日2026-07-18)。

3-4. 詰まりポイント・アンチパターン

IDE Toolkitsへの移行時に実務でつまずきやすい点を整理します。

これらの詰まりポイントは、いずれも「Cloud9ではブラウザ完結・ロール直付けだった」という前提を引きずったまま移行を進めることが原因です。IDE Toolkitsは手元のIDE・認証情報プロファイルを前提とした構成であることを踏まえ、事前に3-3のセットアップ手順を一通り確認したうえで移行に着手することをおすすめします。

4. 移行先② — AWS CloudShell への移行

4-1. CloudShell が適する用途

2-3の判断軸で「ブラウザ完結の軽量なCLI操作・ハンズオン中心の使い方」に該当した場合、移行先はAWS CloudShellが第一候補です。CloudShellはAWSマネジメントコンソールに内蔵されたブラウザベースのシェル環境で、AWS CLIがプリインストール・認証済みの状態で提供されるため、追加のインストール作業なしにログインするだけで利用を開始できます。

以下のような使い方をCloud9でしていた場合、CloudShellへの移行が特に効果的です。

• ちょっとしたAWS CLIコマンドの実行・動作確認が中心で、本格的なコード編集はほとんど行っていない
• 研修・ワークショップの参加者に、追加インストール不要ですぐ使えるCLI環境を提供したい
• Cloud9環境をEC2インスタンス無しの軽量な用途(スクリプト実行・簡易な検証)にのみ使っていた

逆に、コードエディタでの本格的な編集・デバッガの利用が中心だった場合は、CloudShellでは代替できないため§3のIDE Toolkitsへの移行を検討してください。

4-2. Cloud9ターミナル → CloudShellの対応

Cloud9で使っていた主要機能が、CloudShellの何に対応するかを整理します。

CloudShellはあくまで「ブラウザ完結のCLI環境」であり、Cloud9のようなコードエディタ・デバッガは提供されません。この点がIDE Toolkitsとの最大の違いであり、Cloud9でコード編集をしていたワークロードをそのままCloudShellへ移行できない点に注意してください。

4-3. 永続ストレージ/セッション制約(公式情報に基づく正確な値)

CloudShellへの移行で特に見落とされやすいのが、Cloud9とは異なる永続ストレージ・セッションの制約です。以下は公式ドキュメントに基づく正確な値です(取得日2026-07-18)。

Cloud9はEC2インスタンスにアタッチされたEBSボリューム(GB〜数十GB規模が一般的)を利用していたのに対し、CloudShellの永続ストレージは1リージョンあたり1GBに固定されています。この差は、以下のようなケースで移行時の詰まりポイントになります。

• Cloud9環境内に大きめのビルド成果物・依存パッケージ・データファイルを保持していた場合、CloudShellの1GB制約に収まらない
• 長時間の連続処理(バッチ処理・大量データの処理)をターミナルで実行していた場合、12時間の連続セッション上限やアイドルタイムアウトに引っかかる可能性がある
• 120日間データにアクセスしないと自動削除されるため、たまにしか使わない環境の設定・スクリプトを永続ストレージだけに置いていると消失するリスクがある

これらの制約に該当する使い方をしていた場合は、永続ストレージに依存せずGitリポジトリやS3等の外部ストレージへ成果物を保存する運用に切り替えることをおすすめします。

出典: AWS CloudShellのService quotas and restrictions(公式ドキュメント)(取得日2026-07-18)。

4-4. 移行手順(概略)

AWS公式の移行ブログでは、CloudShellの利用開始は「マネジメントコンソールのCloudShellアイコンをクリックし、画面の案内に従うだけ」とシンプルに案内されています。実際の移行手順は以下のとおりです。

1. CloudShellの起動確認: マネジメントコンソール右上のCloudShellアイコンをクリックし、東京リージョンを含む利用予定のリージョンで起動できることを確認します。
2. AWS CLI操作の疎通確認: プリインストール済みのAWS CLIで、これまでCloud9のターミナルから実行していた代表的なコマンド(aws s3 ls等)が問題なく実行できることを確認します。IAMロールを別途アタッチする必要はなく、コンソールのログインセッションの権限がそのまま使われます。
3. 永続ストレージへの必要なファイルの移行: Cloud9環境内にあるスクリプト・設定ファイルのうち、CloudShellでも継続して使うものを、1GBの容量制約を踏まえて選別し、CloudShellの永続ストレージ(ホームディレクトリ)へコピーします。容量に収まらない成果物はGitリポジトリ・S3等の外部ストレージへ移行します。
4. (EC2連携を使っていた場合)SSH接続の設定: CloudShellから対象EC2インスタンスへSSH接続する運用に切り替えます。EC2 Instance Connectを使う場合は、対象インスタンスのセキュリティグループでCloudShellからのSSH接続を許可する設定が必要です。
5. 既存Cloud9環境の退避・削除: 移行完了後は、Cloud9のEC2インスタンス(EC2連携型環境の場合)を削除し、不要な課金が発生しないようにします。この手順はAWS公式の移行ブログでも明示的に案内されています。

出典: AWS公式移行ブログ、AWS CloudShell公式ドキュメント(Service quotas and restrictions)(いずれも取得日2026-07-18)。

4-5. 詰まりポイント・アンチパターン

CloudShellへの移行時に実務でつまずきやすい点を整理します。

CloudShellはCloud9のターミナル機能を軽量に引き継げる一方、永続ストレージ・セッションの制約はCloud9とは前提が異なります。移行前に4-3の制約値を確認し、自分の使い方がこれらの制約に収まるかを見極めておくことが、移行後のつまずきを防ぐ最大のポイントです。

5. Cloud9 機能の対応マッピングと移行手順

§3・§4では、IDE Toolkits・CloudShellそれぞれについて個別に機能対応を整理しました。ここでは両者を横並びにした総合マッピング表と、移行先を問わず共通する全体の移行手順を整理します。すでに移行先を決めている場合も、他方の移行先で何が代替できないかを把握しておくと、併用構成を検討する際の判断材料になります。

5-1. Cloud9機能 → 移行先 総合対応マッピング表

Cloud9の主要機能ごとに、IDE Toolkits・CloudShellそれぞれでの対応状況を一覧化します。

この表からも分かるとおり、「コード編集・デバッグ」の系統はIDE Toolkitsが一手に引き継ぎ、「CLI操作・ハンズオン」の系統はCloudShellが引き継ぐという役割分担が明確です。環境共有機能だけは、どちらの移行先にもCloud9と同じ形の代替が存在しないため、移行先の選定にかかわらず共通の課題として扱う必要があります。

機能カバレッジで見た移行先選定の再確認:

上記の総合マッピング表を俯瞰すると、Cloud9の8機能のうちIDE Toolkitsは6機能(ブラウザIDE本体・ターミナル・デバッガ・EC2連携・プレビュー・リソースエクスプローラ)を実質的にカバーする一方、CloudShellがカバーするのはターミナル・EC2連携(SSH経由)・AWS CLI操作の3機能に留まります。この非対称性は、「迷ったらIDE Toolkits」という単純な結論を意味するわけではありません。CloudShellが担う「追加インストール不要ですぐ使える」という特性そのものが、ハンズオン・研修用途では機能カバレッジよりも重要な判断材料になり得るためです。2-3で整理した開発スタイルの判断軸を優先し、この表はあくまで「選んだ移行先が具体的に何をカバーするか」の確認に使ってください。

5-2. 移行の全体手順(移行先共通のフロー)

§3-3(IDE Toolkits)・§4-4(CloudShell)ではそれぞれの移行先固有の手順を扱いました。ここでは、移行先を問わず共通する全体の流れを整理します。

1. 現状の棚卸し(2-3参照): aws cloud9 list-environments・aws cloud9 describe-environmentsで運用中のCloud9環境を全て洗い出し、各環境の利用頻度・ランタイム・EC2連携有無・環境共有の利用状況を記録します。
2. 移行先の選定(2-3の判断フロー): 棚卸し結果をもとに、環境ごとに「本格的なコード編集・デバッグ中心」か「ブラウザ完結のCLI操作・ハンズオン中心」かを分類し、IDE Toolkits・CloudShellのどちらに移行するかを決定します。複数環境がある場合、環境ごとに異なる移行先を選ぶことも可能です。
3. コード資産のバックアップ: 移行作業を始める前に、Cloud9環境内の未コミットの変更を含むコード資産をGitリポジトリへコミット、またはS3等の外部ストレージへバックアップします。CloudShellへ移行する場合は特に、1GBの永続ストレージ制約(§4-3)を踏まえた選別も同時に行います。
4. 移行先のセットアップ: IDE Toolkitsの場合は§3-3の手順(拡張機能インストール・認証設定・EC2接続設定)、CloudShellの場合は§4-4の手順(起動確認・CLI疎通確認・SSH接続設定)に従ってセットアップします。
5. 並行運用期間での動作確認: 既存のCloud9環境を残したまま、移行先の環境で実際の開発・運用作業を一定期間試し、Cloud9側で行っていた作業が問題なく移行先で完結できるかを確認します。この並行運用期間の長さは、環境の重要度・複雑さに応じて調整してください。
6. 既存Cloud9環境の退避・削除: 並行運用期間で問題がないことを確認できたら、Cloud9のEC2インスタンス(EC2連携型環境の場合)を削除します。この手順の詳細な注意点は§6で扱います。

Cloud9環境を複数運用している場合は、まず影響範囲の小さい環境から着手するとよいでしょう。目安は、利用頻度が低く、関わるチームメンバーも少ない環境です。そうした環境でこの6ステップを一通り実施し、手順や詰まりポイントを確立したうえで、残りの環境へ順次展開していく進め方が実務的です。1つの環境で確立した手順・詰まりポイントの知見は、他の環境への展開時にそのまま活用できます。

移行先ごとの全体手順の違い:

この違いを踏まえたうえで移行を進めることで、移行先固有の制約に気づかないまま作業を進めてしまうリスクを減らせます。

6. 移行チェックリストとまとめ

6-1. 移行前後の検証項目チェックリスト

§5で整理した移行の全体手順を踏まえ、移行前・移行後それぞれで確認しておくべき項目をチェックリストとして整理します。

移行前チェックリスト:

移行後チェックリスト:

移行後チェックリストの最後の項目(並行運用での問題有無)は、次の6-2で扱うロールバック観点とあわせて確認してください。

6-2. 既存Cloud9環境の退避・削除の注意点

移行後チェックリストで問題がないことを確認できたら、既存のCloud9環境を退避・削除する段階に進みます。ここで改めて押さえておくべきなのが、2-1で整理したCloud9の現況です。

Cloud9の完全シャットダウン日は、本記事執筆時点(取得日2026-07-18)で未告知であり、既存顧客は引き続き通常どおり利用を継続できます。 そのため、本記事の内容は「今すぐ全てのCloud9環境を強制的に削除しなければならない」ことを意味するものではありません。移行はAWS公式が推奨する計画的な取り組みであり、猶予期間を「移行先の選定・並行運用での検証・チームへの周知」に充てたうえで、準備が整った環境から順に退避・削除を進めるのが実務的な進め方です。

既存Cloud9環境の退避・削除にあたっては、以下の点に注意してください。

• 削除前に必ずコード資産のバックアップを確認する: Cloud9のEC2インスタンス(EC2連携型環境の場合)を削除すると、EBSボリューム上のデータも失われます。§5-2で整理したバックアップ手順(Gitリポジトリへのコミット、もしくは外部ストレージでの退避)が完了していることを、削除の実行者以外の目でも再確認することをおすすめします。
• 並行運用期間を十分に確保してから削除する: 移行先での動作確認が完了した直後にすぐ削除するのではなく、一定期間の並行運用を経てから削除する方が安全です。並行運用期間の目安は環境の重要度に応じて調整してください(日常的な開発環境であれば数週間、スポット利用のハンズオン環境であれば数日程度が目安になります)。
• 削除は環境単位で段階的に行う: 複数のCloud9環境を運用している場合、全環境を一括で削除するのではなく、影響範囲の小さい環境から段階的に削除を進めることで、想定外の問題が発生した際の影響を限定できます。
• 不要な課金が発生しないことを確認する: EC2連携型のCloud9環境は、削除せずに放置するとEC2インスタンス・EBSボリュームの課金が継続します。移行完了後は速やかに削除し、AWS請求ダッシュボードで課金が停止したことを確認することをおすすめします。

6-3. ロールバック観点

移行後に想定外の問題が発生した場合に備え、ロールバックの観点も事前に押さえておきます。

• Cloud9環境を即座に削除しない: 6-2で述べたとおり、Cloud9の完全シャットダウン日は未告知であるため、移行後すぐにCloud9環境を削除する必要はありません。並行運用期間中はCloud9環境を残しておき、移行先で問題が見つかった場合にCloud9側の作業へ一時的に戻れる状態を維持しておくことが、実質的なロールバック手段になります。
• 移行先で解決できない問題を切り分ける: 移行後に生産性が落ちたと感じた場合、それが「移行先ツールへの不慣れによる一時的なもの」なのか、「機能的にCloud9の代替になっていない構造的なもの」なのかを切り分けます。前者であれば学習期間を確保して移行を継続し、後者であれば§2-3の判断軸に立ち返って移行先の選定自体を見直します。
• 段階的な削除により後戻りコストを抑える: 6-2で述べた環境単位での段階的な削除も、ロールバックの観点から重要です。全環境を一括削除してしまうと、問題が見つかった際にCloud9側へ戻る選択肢が失われますが、段階的に進めていれば未削除の環境はCloud9側での作業を継続できます。

6-4. §1〜§6のまとめ

本記事では、新規受付終了したAWS Cloud9から、AWS公式が推奨するIDE Toolkits・CloudShellへの移行について、以下の流れで整理しました。

改めて強調しておきたいのは、本記事の目的が「Cloud9からの即時の強制移行を促す」ことではないという点です。新規受付終了(2024-07-25)以降も既存顧客は通常どおり利用を継続でき、完全シャットダウン日は本記事執筆時点(取得日2026-07-18)で未告知です。一方で、AWS自身が移行ブログを公開してIDE Toolkits・CloudShellへの移行を案内している以上、猶予がある今のうちに移行先を選定し、計画的に移行を進めておくことが、将来予告なく完全シャットダウン日が確定した場合の混乱を避ける最も確実な方法です。

自分の開発スタイルがまだ2-3の判断軸で整理できていない場合はそこから、移行先がすでに決まっている場合は該当する§3・§4の手順から、そしてどの移行先でも共通する機能対応・移行手順の全体像を確認したい場合は§5から、それぞれ読み進めてください。§6のチェックリストは、実際の移行作業が該当の段階に進んだ際、移行前・移行後それぞれの場面で見返しながら活用することをおすすめします。