Amazon ECS が非 root コンテナでの EBS ボリュームマウントをサポート

はじめに

2025 年 11 月 7 日、AWS は Amazon Elastic Container Service（ECS）向けの重要なセキュリティ機能を発表しました。
ECS が非 root ユーザーとして実行されるコンテナに対して、Amazon Elastic Block Store（EBS）ボリュームへの安全な読み書きを自動的にサポートするようになりました。
この機能は全 AWS 商用リージョンで即座に利用可能となっており、EC2、Fargate、ECS Managed Instances のすべての起動タイプで利用できます。
本記事では、新機能の詳細、従来との違い、実際の使い方、コストや制限事項についてまとめています。

新機能の概要

今回発表された新機能により、非 root ユーザーとして実行されるコンテナでも、EBS ボリュームへの読み書きが安全に行えるようになりました。

主な特徴

主な特徴としては以下の 3 つです。

• 自動権限管理
• セキュリティの向上
• 全起動タイプでサポート

自動権限管理

ECS が自動的に EBS ボリュームのファイルシステム権限を設定します。
手動での権限設定やカスタムスクリプトは一切不要です。

セキュリティの向上

コンテナを非 root ユーザーとして実行できることで、特権昇格のリスクを軽減します。
最小権限の原則に従ったセキュアなコンテナ運用が実現できます。

全起動タイプでサポート

EC2、Fargate、ECS Managed Instances のすべての起動タイプで利用可能です。
ボリュームの root 所有権は維持されたまま、非 root ユーザーにも適切なアクセス権限が付与されます。

仕組み

ECS は以下のプロセスでボリューム権限を自動管理します。
タスク定義の user フィールドからユーザー ID を検出し、EBS ボリュームのマウント時に自動的にファイルシステム権限を調整します。
指定されたユーザー ID に対して読み書き権限を付与しつつ、ボリュームの root 所有権は維持されます。
これにより、コンテナ側での追加設定なしに非 root ユーザーでの読み書きが可能になり、手動での権限管理やカスタムエントリーポイントスクリプトが不要になりました。

何が変わったのか

今回発表された新機能により、ECS での非 root コンテナ運用が大きく変わりました。
従来の課題と新機能による変化を見ていきましょう。

従来の課題

主な課題としては以下の 3 つがありました。

• root ユーザーでの実行が必須
• 複雑な回避策の実装と運用負荷
• コンプライアンス対応の困難さ

root ユーザーでの実行が必須

ECS タスク内のコンテナが EBS ボリュームに書き込むには root ユーザーとして実行する必要がありました。
非 root コンテナの実行は CIS Kubernetes Benchmark をはじめとする業界標準で推奨されていますが、永続ストレージとして EBS を利用する場合は実現が困難でした。

複雑な回避策の実装と運用負荷

非 root ユーザーで実行する場合、Init コンテナでボリュームの権限を変更するか、カスタムエントリーポイントスクリプトで起動時に権限を調整する必要がありました。
どちらの実装方法でも以下のような運用上の問題がありました。

• Init コンテナやスクリプトのメンテナンス負荷
• デプロイ時間の増加（Init コンテナの実行完了待ち）
• アプリケーションに本来不要な依存関係（sudo 等）をイメージに含める必要
• トラブルシューティングの複雑化

コンプライアンス対応の困難さ

セキュリティ監査で「なぜ root コンテナを使用しているのか」「権限昇格のリスクをどう軽減しているか」「回避策のセキュリティ検証」などの説明が必要でした。
金融・医療系など厳格なセキュリティ要件を持つ業界では、root コンテナの実行が禁止されているケースも多く、ECS での永続ストレージとして EBS の利用を断念せざるを得ない状況もありました。

新機能による変化

新機能により、従来の課題がすべて解決されました。

非 root ユーザーでの実行が可能に

ECS が自動的に EBS ボリュームのファイルシステム権限を設定することで、非 root ユーザーとして実行されるコンテナでも安全に読み書きできるようになりました。

自動権限管理

Init コンテナやカスタムエントリーポイントスクリプトが完全に不要になりました。
タスク定義で user フィールドを指定するだけで、ECS が自動的に適切な権限を付与します。

コンプライアンス対応の簡素化

非 root コンテナでの実行が標準機能としてサポートされることで、セキュリティ監査での説明が大幅に簡素化されました。
業界標準のセキュリティフレームワーク（CIS Benchmark、NIST 等）への準拠も容易になり、コンプライアンス対応のコストが削減されます。

使い方

新機能の使い方を、タスク定義の作成から動作確認まで順を追って説明します。

動作確認用サンプル

非 root ユーザーを指定したタスク定義を作成します。

タスク定義

{
  "family": "non-root-ebs-demo",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::<account-id>:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "test-app",
      "image": "busybox:latest",
      "user": "1000",
      "essential": true,
      "command": [
        "sh",
        "-c",
        "echo 'Starting test...'; whoami; id; echo 'Creating file...'; touch /data/test.txt; ls -l /data/test.txt; echo 'Writing to file...'; echo 'Hello from non-root user!' > /data/test.txt; cat /data/test.txt; echo 'Test completed successfully!'; sleep 30"
      ],
      "mountPoints": [
        {
          "sourceVolume": "data-volume",
          "containerPath": "/data",
          "readOnly": false
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/non-root-ebs-demo",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "volumes": [
    {
      "name": "data-volume",
      "configuredAtLaunch": true
    }
  ]
}

タスクの実行

作成したタスク定義を使用してタスクを実行します。

1. ECS コンソールのタスク定義画面ページより「デプロイ」>「タスクの実行」を選択
2. 「ボリューム」セクションに移動
3. EBS ボリューム設定を追加

動作確認

CloudWatch Logs コンソールで「/ecs/non-root-ebs-demo」ログループを開き、以下のようなログが出力されていることを確認します。

実行ログ

Starting test...
whoami: unknown uid 1000
uid=1000 gid=0(root) groups=0(root),939932
Creating file...
-rw-r--r-- 1 1000 939932 0 Nov 10 08:53 /data/test.txt
Writing to file...
Hello from non-root user!
Test completed successfully!

このログから以下が確認できます。

• ユーザーが UID 1000 で実行されている（whoami は busybox にユーザー名が登録されていないため失敗しますが、問題ありません）
• /data/test.txt が正常に作成されている
• ファイルの所有者が 1000 になっている
• ファイルへの書き込みが成功している

これで、非 root ユーザー（UID 1000）が EBS ボリュームに対して読み書きできることが確認できました。
より詳細な確認を行いたい場合は、ECS Exec でコンテナに接続することもできます。

コストと制限事項

新機能を利用する前に知っておくべきコストと制限事項について説明します。

料金体系

この機能自体に追加料金は発生しませんが、EBS ボリュームの標準料金が適用されます。

EBS ボリューム

ストレージ料金（東京リージョン）

ボリュームタイプ	料金	用途
gp3	$0.096/GB/月	汎用（推奨）
gp2	$0.12/GB/月	汎用（従来型）
io2	$0.142/GB/月	高性能 DB・高 IOPS 要件
st1	$0.054/GB/月	スループット重視

IOPS・スループット料金（gp3 の場合）

• 基本（3,000 IOPS、125 MB/s）：無料
• 追加 IOPS：$0.006/IOPS/月（3,000 IOPS超過分）
• 追加スループット：$0.048/MB/s/月（125 MB/s超過分）

コスト最適化のポイント

• まずは非本番環境で実際のボリューム使用量を測定
• 適切なボリュームタイプを選択
• 不要なタスクは停止

制限事項

機能面の制限

• タスクあたり 1 つの EBS ボリュームのみアタッチ可能
• 既存の EBS ボリュームを直接アタッチすることは不可で、新規ボリュームのみ作成可能（スナップショットからの復元は可能）

運用上の注意点

• デフォルトでタスク終了時にボリュームは自動削除
• Amazon ECS infrastructure IAM role が必須
• 同一タスク内の複数コンテナで同じボリュームを共有可能だが、ユーザー ID が異なる場合は権限設定に注意が必要

まとめ

今回発表された新機能は、ECS における非 root コンテナ運用を大幅に簡素化する重要な改善です。
手動での権限管理やカスタムスクリプトが不要になり、セキュリティベストプラクティスに準拠した運用が容易になりました。
この機能自体に追加コストは発生せず（EBS ボリュームの標準料金のみ）、全起動タイプで即座に利用可能です。
まずは非本番環境で実際に試してみることをお勧めします。

参考リンク

https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-ecs-non-root-container-managed-ebs-volumes/
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html