ECS の EC2 起動タイプが S3 Files に対応した。Fargate・ECS Managed Instances に続く3つ目で、S3 のデータを移行なしにファイルシステムとしてマウントできる。
3種類 S3 Files が使える ECS の起動タイプ Fargate と ECS Managed Instances に EC2 起動タイプが加わった（2026年9月16日付の AWS 告知）
Amazon ECS の EC2 起動タイプで動くタスクが、Amazon S3 Files のボリュームをマウントできるようになった。AWS の告知は2026年9月16日付。S3 Files はこれまで AWS Fargate と ECS Managed Instances のタスク向けで、ここに EC2 起動タイプが加わり、ECS の3つの起動タイプすべてで S3 のデータに同じ形で届くようになった。
告知の言い方では、コンテナ化されたアプリケーションを S3 のデータへ共有ファイルシステムとして直接つなぐ機能だ。ファイルベースのアプリケーション、AI エージェント、データ処理のワークロードが、コードを変えず、ファイルを複製したりステージングしたりせずに S3 上のデータで動く、としている。
Fargate と ECS Managed Instances はすでに対応済みで、今回の新規対象ではない。今回の差分は EC2 インスタンス上のタスクだ。S3 に置いたデータをファイルとして読ませるために自分で仕組みを用意していた EC2 起動タイプの構成が、今回の検討対象になる。
判断に要る条件は少ない。ECS を EC2 起動タイプで動かしていること、そのタスクが S3 のデータをファイルとして扱いたいこと、この二つが適用範囲だ。どちらかが外れるなら読み飛ばしていい。
AWS はこの追加を、3つの起動タイプにまたがって S3 Files へ一貫してアクセスできる状態になった、と位置づけている。同じワークロードを起動タイプ違いで動かしているチームなら、S3 のデータの渡し方を起動タイプごとに分けて設計する理由が一つ減る。
Amazon S3 Files は Amazon EFS 上に構築された共有ファイルシステムで、AWS のコンピュートリソースと S3 のデータを直接つなぐ、というのが告知の定義だ。挙げられている性質は、完全なファイルシステムの意味論、低レイテンシ、そしてデータが S3 から出ないこと。S3 バケットの新しいデータでも既存のデータでも働き、移行は不要だと明記されている。
一方で、EFS 上に構築されているという説明と、データが S3 から出ないという説明が、どう両立するのかまでは書かれていない。EFS のファイルシステムを自分で用意するのか、ボリュームがタスク定義でどう表現されるのかも、この文面からは読み取れない。
告知は、S3 Files のボリュームをマウントすれば、S3 のデータを別の場所へコピーまたはステージングせず、標準のファイルシステム操作で読み書きできるとしている。どの既存工程が置き換わるかは構成によるため、ローカルディスクへの事前コピーだけを指すとは限らない。
読み書きの両方が対象に入っている点は押さえておきたい。読み取り専用のマウントとしては説明されていない。
提供範囲は、すべての AWS 商用リージョンと AWS GovCloud (US) リージョン。リージョンの順次展開を待つ種類の変更ではない。GovCloud (US) が告知の時点で含まれている点は、リージョン条件で構成を分けているチームには効く。
文面が触れていないものは、それより多い。料金、必要な IAM 権限、ECS エージェントや AMI のバージョン条件、タスク定義での書き方、S3 バケット側の前提。EC2 起動タイプはインスタンスを自分で持つ分だけ条件が増えるかもしれないが、それは推測であって、この告知から確認できることではない。
確実なのは、起動タイプを選ぶときの判断材料から「S3 Files が使えるかどうか」が抜けた、というところまでだ。移行が要らないと書かれている以上、すでに S3 にあるデータをそのままマウントして確かめられるかどうかが、次に見る点になる。
