ECS のタスクをクラウド開発環境として使う

ECS のタスクをクラウド開発環境として使う

AWS上でECSを使ったセキュアなクラウド開発環境の構築方法を紹介します。ユーザーごとに隔離された開発環境を動的に作成・削除する構成例と、実装時の注意点をまとめました。
2026.10.05

はじめに

こんにちは、AI 事業本部の Kanaru です。

AWS を使ってクラウド開発環境を動的に作成・削除する際、ECS のタスクが便利です。しかし、実際に ECS のタスクでクラウド開発環境を扱うための構築をすると、様々な注意点が浮かび上がりました。
本記事では、ECS をクラウド開発環境として使うための構成例を紹介します。

本記事の実装は以下にあります。この実装では、ECS で Claude Code の使用が可能な開発環境を構築します。

https://github.com/kanaru0928/cm-ecs-claude-code

対象読者

  • AWS 上にセキュアなクラウド開発環境を構築したい方
  • ユーザーごとに隔離された開発環境を用意したい方
  • ブラウザで完結する開発環境を用意したい方

この記事で紹介すること

  • ECS のタスクを動的に開始し、URL を発行する方法

この記事で紹介しないこと

  • SageMaker Code Editor や Coder で類似のソリューションを構築する方法

類似ソリューション

クラウド開発環境を動的に作成・削除することが目的の場合、今回紹介する以外に以下のソリューションが利用可能です。

SageMaker Code Editor

機械学習の統合開発環境を提供する SageMaker AI の Code Editor です。IAM Identity Center や SageMaker Domain のユーザープロファイルによるアクセス制御が可能です。設定次第では ID プロバイダとの接続も可能です。詳細は以下の記事をご覧ください。

https://dev.classmethod.jp/articles/sagemaker-code-editor-as-a-sandbox/

Coder

セルフホスト型のクラウド開発環境です。EKS にデプロイするテンプレートが提供されています。

https://coder.com/docs/install/cloud/aws-marketplace

構成

以下のような構成にします。

cde-infra.drawio.png

ECS タスク(Code Server)

動的に作成される環境です。今回は codercom/code-server を動作させています。外部とは NAT Gateway を経由して接続できます。

ECS サービス(Proxy)

ECS タスクへのアクセス制御を行います。リクエストが来たら、以下の動作を実施します。

  1. ユーザーが認証されているかを確認
  2. 認証されていた場合、ユーザーに紐づくタスクの IP アドレスを参照
  3. 指定 IP アドレスにプロキシ

Code Server は WebSocket の通信もあるので、Proxy でも考慮する必要があります。

Lambda + API Gateway

ECS タスクを作成・削除します。作成時は完了までポーリングで待機し、使用可能になってから ENI に振られた IP アドレスを DynamoDB に登録します。API Gateway の Authorizer で認証情報を確認しています。

Web UI

API を叩くための Web UI です。静的サイトを S3 と CloudFront でホスティングしています。

動作確認

Web UI にアクセスし、ログインしてタスクを起動すると Code Server へのリンクが出現します。

active.png

ALB のリンクを踏むと、Proxy によって自動的にタスクにルーティングされ、開発環境の画面に遷移します。

coder.png

タスクを停止すると「No running task」と表示され、Code Server にアクセスできなくなります。

比較

SageMaker Code Editor と比較して、この方法の良い点と悪い点を紹介します。

良い点

  • AWS IAM や IAM Identity Center に縛られない方法でユーザーを管理できる
  • ユーザーは AWS のマネジメントコンソールを経由せずとも使用できる
  • データの永続化を EFS に縛られずできる
    • → バックアップ対応を柔軟にできる
  • 要件に合わせた拡張が柔軟に可能

悪い点

  • 構築・運用の工数が多い
  • AWS マネージドでない部分の障害点が多い
  • Proxy の常駐のための金銭的コストがかかる
  • 独自ドメインが必要

構築にあたっての注意点

ALB のドメイン

ALB には自動的に割り振られるドメインがありますが、そのドメインには TLS 証明書が設定されていません。そのため、デフォルトのドメインで運用する場合には、以下の対応が必要です。

  1. オレオレ証明書を作成して ACM に登録する
  2. 作成した証明書を使用する端末で信頼するように設定する

対応1はアクセスのために、対応2は一部の拡張機能等で Service Worker を使用するために必要です。
しかし、これらの設定はセキュリティ上の観点で実運用としての導入は現実的とは言えません。よって、独自ドメインの用意が必須となります。

Lambda の実行

現状の構成では、Lambda はタスクのプロビジョニングが終了するまで実行し続けたままです。このポーリングを EventBridge に置き換えることで、Lambda の実行時間を抑えられます。
一方、Web UI 側でタスクの状況をリアルタイムで取得するためには工夫が必要です。

Fargate のタスク廃止

AWS Fargate は Fargate Spot かオンデマンドかに関わらず、AWS の保守作業の一環で不定期に停止される場合があります。そのため、長期間稼働しているタスクについては、ユーザーが意図しないタイミングで停止される場合があります。

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-maintenance.html

対策として、単発タスクではなくサービスを動的に作成するか、タスクのライフサイクルを管理する機構(例えば最大稼働時間を8時間に制限するなど)を設ける方法が考えられます。

おわりに

本記事では、柔軟に作成・削除が可能なクラウド開発環境を実際に ECS で構築した例を紹介しました。
IDE が使用できなかったり、リソースをプライベートサブネットで運用する必要があったりする場合に、柔軟な開発環境を用意する1つの方法として有用だと感じました。

この記事をシェアする

関連記事