はじめに
Amazon ECS は、Amazon S3 Files のサポート対象を EC2 起動タイプにも拡張したと発表しました。これまで Fargate と ECS Managed Instances でしか使えなかった機能が、EC2 起動タイプでも利用できるようになった、というアップデートです。
ただし、この発表には少し引っかかる点があります。AWS 公式の Developer Guide には、今なお「S3 Files は EC2 起動タイプでは現時点でサポートされておらず、起動時にタスクが失敗する」という記載が残っているのです。同じ AWS の公式情報の中で、発表とドキュメントの記載が食い違っている状態です。実際にどちらが正しいのか、EC2 起動タイプでタスクを起動して確かめてみました。
以下では、具体的に何が変わったのか、そして実際にタスク定義へどう組み込めばよいのかを、この食い違いの検証結果を交えて見ていきます。ECS を運用しているインフラ・プラットフォームエンジニアの方はもちろん、導入可否を判断するマネージャー層の方にも読んでいただける内容を目指します。
何が変わったのか
今回のアップデートで変わった点を整理すると、以下のようになります。
| 項目 | 変更前 | 変更後(公式発表上) |
|---|---|---|
| 対応する起動タイプ | Fargate、ECS Managed Instances | Fargate、ECS Managed Instances、EC2 |
| コンテナから S3 データを扱う方法 | アプリケーション側で S3 API を呼び出すか、起動時にデータをコピー・ステージングする必要があった | タスク定義に S3 Files ボリュームを指定するだけで、標準的なファイルシステム操作で読み書きできる |
| 利用可能リージョン | ー | 全 AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用可能 |
ポイントは、S3 Files 自体が新設された機能ではなく、あくまで「対応する起動タイプの範囲」が広がった、という点です。S3 Files は Amazon EFS の技術基盤上に構築されたサービスで、データを S3 バケットに保存したまま、EFS のファイルシステムインターフェースを介して低レイテンシーなアクセスを提供します。この仕組みにより、S3 の耐久性・スケーラビリティを享受しながら、既存のファイルベースのアプリケーションをコード変更なしに動かせる、という点が今回のアップデートの本質です。
実装イメージ
タスク定義への組み込みは、専用の s3filesVolumeConfiguration パラメータを使うだけです。ボリュームとして S3 ファイルシステムの ARN を指定し、コンテナのマウントポイントに紐付けます。
{
"family": "s3files-ec2-sample",
"requiresCompatibilities": ["EC2"],
"networkMode": "bridge",
"taskRoleArn": "arn:aws:iam::<account-id>:role/s3files-task-role",
"volumes": [
{
"name": "s3files-volume",
"s3filesVolumeConfiguration": {
"fileSystemArn": "arn:aws:s3files:<region>:<account-id>:file-system/<fs-xxxxx>"
}
}
],
"containerDefinitions": [
{
"name": "app",
"image": "<your-image>",
"cpu": 256,
"memory": 512,
"essential": true,
"mountPoints": [
{
"sourceVolume": "s3files-volume",
"containerPath": "/mnt/s3files"
}
]
}
]
}
s3filesVolumeConfiguration には、この他に rootDirectory(マウントするディレクトリ、未指定時は /)、transitEncryptionPort、accessPointArn をオプションで指定できます。転送暗号化とタスク IAM ロールは必須項目で、無効化するオプションはありません。
タスク IAM ロールには、S3 ファイルシステムへの接続・操作権限と、S3 オブジェクトへの読み取り・書き込み権限の両方が必要です。実際に動作確認した範囲では、最低限以下のようなポリシーで読み書きできました。なお ssmmessages の権限は、コンテナ内を直接確認する ECS Exec を使う場合に必要なもので、S3 Files 自体の読み書きには不要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3files:ClientMount", "s3files:ClientWrite"],
"Resource": "arn:aws:s3files:<region>:<account-id>:file-system/<fs-xxxxx>"
},
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::<bucket-name>",
"arn:aws:s3:::<bucket-name>/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
なお、S3 ファイルシステムとマウントターゲット自体は、タスク定義とは別に事前に作成しておく必要があります。また S3 ファイルシステムは、タスクが実行される VPC・サブネットからアクセスできるようネットワークを設定しておく必要があります。
動作確認
前章の設定をもとに、実際に EC2 起動タイプで S3 Files ボリュームを持つタスクを起動して確認しました。検証環境は ap-northeast-1 リージョンの商用アカウントで、実施日は 2026 年 9 月 23 日です。
run-task を EC2 起動タイプで実行すると、タスクの attachments に S3 Files のマウント情報が記録され、エラーなく起動しました。
{
"attachments": [
{
"type": "S3Files",
"status": "CREATED",
"details": [
{ "name": "volumeId", "value": "fs-0e6f8be10c153c3a0" },
{ "name": "volumeName", "value": "s3files-volume" }
]
}
],
"lastStatus": "RUNNING",
"launchType": "EC2"
}
タスクが RUNNING になった後、ECS Exec でコンテナ内に入り、マウントしたパスにファイルを書き込んで内容を確認したところ、S3 バケット側にも同一内容が反映されていました。
# コンテナ内
$ cat /mnt/s3files/verify.txt
verified-1790151689
# S3バケット側
$ aws s3 cp s3://<bucket-name>/verify.txt -
verified-1790151689
コンテナから書き込んだファイルが、非同期で S3 バケット側のオブジェクトとしても正しく反映されることを確認できました。EC2 起動タイプでも、Fargate や ECS Managed Instances と同様に S3 Files が利用できています。
書き込みから S3 バケット側への反映までの時間も計算できます。コンテナ内で書き込んだ時刻(ファイルの中身に埋め込んだ Unix 時刻 1790151689 = 2026-09-23 08:21:29 UTC)と、aws s3 ls で確認できた S3 オブジェクトの最終更新時刻(2026-09-23 08:23:04 UTC)の差から、この検証では約 95 秒(1 分 35 秒)で反映されたことが分かります。
なお、今回の確認は 1 つのファイルを書き込んで読み出せるかを見る簡易的なものです。スループットや大量ファイルでの挙動、長時間稼働時の安定性までは検証できていません。この点は今後の検証課題です。
参考として、コンテナインスタンスの ECS エージェント・AMI のバージョンも記載します。
| 項目 | 値 |
|---|---|
| AMI ID | ami-08d556eca88f9a61c |
| ECS agent version | 1.107.0(agentHash: cc1e779d) |
| Docker version | 25.0.16 |
導入時のチェックポイント
実際に動作確認できたとはいえ、導入前に確認しておきたい点があります。
今回の検証は、ap-northeast-1 リージョンの商用アカウントで 2026 年 9 月 23 日に実施したものです。本番環境への導入を判断する際は、この記事の内容だけで判断せず、必ず最新のドキュメントもあわせて確認してください。なお、本記事の執筆にあたり AWS への問い合わせやフィードバックの提出は行っていません。記載の食い違いが気になる方は、各自でサポートに問い合わせることをおすすめします。
その上で、実装時に確認しておきたい技術的なポイントを整理します。
| 確認項目 | 内容 |
|---|---|
| タスク IAM ロール | S3 ファイルシステムへの接続・操作権限と、S3 オブジェクトの読み取り・書き込み権限の両方を過不足なく付与する。タスク IAM ロール自体が必須項目のため、付与を忘れると登録時にエラーになる |
| ネットワーク設定 | S3 ファイルシステムのマウントターゲットが、タスクを実行する VPC・サブネットからアクセス可能になっているか、セキュリティグループで NFS ポート(2049)の通信を許可しているかを確認する |
| S3 ファイルシステムの事前作成 | タスク定義側の設定だけでは完結しない。S3 ファイルシステムとマウントターゲットを、あらかじめ別途作成しておく必要がある |
| データ反映のタイムラグ | 前章の実測では約 95 秒でしたが、公式ドキュメント上は「数分程度」とされています。即時反映が必須な用途では考慮が必要です |
活用シーン
AWS の発表では、次のようなユースケースでの活用が想定されています。GPU インスタンス等、特定のハードウェアを必要とする AI/ML ワークロードは EC2 起動タイプで実行されることが多く、S3 上の学習データセットをファイルシステムとして直接参照できる用途が挙げられています。ETL やバッチ処理のようなデータ処理パイプラインでも、S3 上の入力データを直接読み込み、処理結果をそのまま S3 に書き戻す構成が想定されています。また、NFS や EFS を前提に設計された既存のファイルベースアプリケーションを、コード変更なしに EC2 起動タイプの ECS コンテナへ移行する用途も挙げられています。
自分たちのワークロードでこうした効果が実際に得られるかは、今回の検証範囲を超えるため、導入を検討する際はあらためて自分たちの環境で確認することをおすすめします。
まとめ
Amazon ECS の EC2 起動タイプで、S3 Files が実際に動作することを確認できました。これまで Fargate と ECS Managed Instances に限られていた機能が EC2 起動タイプでも使えるようになったことで、GPU インスタンス等、特定のハードウェアが必要なワークロードでも、S3 上のデータをファイルシステムとして直接扱えるようになります。
ただし、本記事執筆時点では AWS 公式の Developer Guide に非対応との記載が残ったままです。検証環境で試してみる分には問題ないと考えますが、本番環境への導入は、Developer Guide 側の記載が更新されるのを待つか、少なくとも自分たちの環境で改めて動作確認を行ってから判断することをおすすめします。本記事で紹介した確認事項もあわせて参考にしてください。