【Security Hub修復手順】[ECS.9] ECS タスク定義にはログ設定が必要です。
かつまたです。
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[ECS.9] ECS タスク定義にはログ設定が必要です。
[ECS.9] ECS task definitions should have a logging configuration
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
このコントロールは、ECSタスク定義の各コンテナ定義にログ記録の設定(logConfiguration)が指定されているかをチェックします。
タスク定義内のすべてのコンテナ定義にlogConfigurationが定義され、それぞれのlogDriverに値が設定されている場合、このコントロールは成功します。
チェックの対象は、タスク定義ファミリーの最新のACTIVEリビジョンです。
次のいずれかに該当するとFAILEDになります。
- 少なくとも1つのコンテナ定義で
logConfigurationが定義されていない - 少なくとも1つのコンテナ定義で
logDriverの値がnullになっている
つまり、コンテナが1つでもログ設定を持たない場合、そのタスク定義は違反として検出されます。
ECSのログ設定でawslogsドライバーを使用すると、コンテナの標準出力・標準エラー出力(STDOUT / STDERR)をAmazon CloudWatch Logsへ転送できます。
ログ設定がない場合、コンテナのログはCloudWatch Logsなどの外部ログ基盤へ自動的には転送されません。特にFargateでは基盤ホストにアクセスできないため、タスク停止後にログを遡って取得できません。
EC2起動タイプでは、Dockerデーモンのデフォルトログドライバーによってコンテナインスタンス上にログが残る場合があります。ただし、コンテナや
インスタンスの削除によってログを失う可能性があるため、永続的なログ保管先として利用することは推奨されません。
この状態では、障害発生時の根本原因の特定や、セキュリティインシデント発生時の調査が困難になります。
以上の理由から、本番環境ではログ設定が必須です。
一方、本番以外の環境では対応は必須ではありません。次のようなケースでは、リスクを評価したうえで例外としてコントロールの無効化を検討できます。
- 開発環境などで、CloudWatch Logsの取り込み・保存コストやログのノイズを避けたい場合
- ECSタスク定義の
logConfigurationを使用しないサードパーティ製の仕組みにより、
必要なログが確実に収集・保管されている場合
修復手順
タスク定義は登録済みのリビジョンを直接変更できません。修復は「logConfigurationを設定した新しいリビジョンを登録する」流れになります。ここではマネジメントコンソールでの操作を紹介します。
事前確認: 現在のタスク定義のログ設定を確認する
修復対象のタスク定義に、本当にログ設定がないことを確認します。あわせて新しいリビジョンの作成に必要な既存設定(イメージ、CPU / メモリ、ネットワークモード、環境変数など)を控えておきます。
今回の例で使用するタスク定義の全文は以下のとおりです。コンテナ定義にlogConfigurationがありません。
修復前のタスク定義JSON
{
"taskDefinitionArn": "arn:aws:ecs:ap-northeast-1:123456789012:task-definition/ecs9-test-taskdef:1",
"containerDefinitions": [
{
"name": "ecs9-test-container",
"image": "public.ecr.aws/docker/library/nginx:latest",
"cpu": 0,
"portMappings": [],
"essential": true,
"environment": [],
"mountPoints": [],
"volumesFrom": [],
"systemControls": []
}
],
"family": "ecs9-test-taskdef",
"networkMode": "awsvpc",
"revision": 1,
"volumes": [],
"status": "ACTIVE",
"requiresAttributes": [
{
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
},
{
"name": "ecs.capability.task-eni"
}
],
"placementConstraints": [],
"compatibilities": [
"EC2",
"FARGATE",
"MANAGED_INSTANCES"
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "256",
"memory": "512",
"registeredAt": "2026-07-31T05:23:51.804Z",
"registeredBy": "arn:aws:sts::123456789012:assumed-role/xxxxxxxxxx/xxxxxxxxxx",
"tags": []
}
CLIで確認する場合は、以下のコマンドで各コンテナのログ設定を抽出できます。nullが返る場合はログ設定がありません。
aws ecs describe-task-definition \
--task-definition <タスク定義ファミリー名> \
--region ap-northeast-1 \
--query 'taskDefinition.containerDefinitions[].{name:name,logConfiguration:logConfiguration}'
修復手順: ログ設定を追加した新しいリビジョンを作成する
既存リビジョンをコピーして一部だけ変更した新しいリビジョンを作成できます。
- ECSコンソールで対象のタスク定義ファミリーを開く
- 最新のアクティブなリビジョンを選択し、「新しいリビジョンの作成」を選択する

- ログ設定を追加したいコンテナの「ログ記録 - オプション」セクションを開き、「ログ収集の使用」にチェックを入れる
- 送信先で「Amazon CloudWatch」を選択する(デフォルトで選択されています)


- 送信先にAmazon CloudWatchを選択すると
logDriverはawslogsになり、主要なパラメータが自動で補完される。
必要に応じてロググループ名やプレフィックスを命名規則に合わせて調整してください。
awslogs-create-groupをtrueに設定してロググループを自動作成する場合は、タスク実行ロールにlogs:CreateLogGroup権限が必要です。
-
タスク定義内にコンテナが複数ある場合は、すべてのコンテナに対して同様にログ設定を追加する(1つでもログ設定がないとコントロールはFAILEDのままです)
-
「作成」を選択して新しいリビジョンを登録する
作成された新しいリビジョンのJSONは以下のとおりです。コンテナ定義にlogConfigurationが追加されています。
修復後のタスク定義JSON
{
"taskDefinitionArn": "arn:aws:ecs:ap-northeast-1:123456789012:task-definition/ecs9-test-taskdef:2",
"containerDefinitions": [
{
"name": "ecs9-test-container",
"image": "public.ecr.aws/docker/library/nginx:latest",
"cpu": 0,
"portMappings": [],
"essential": true,
"environment": [],
"mountPoints": [],
"volumesFrom": [],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/ecs9-test-taskdef",
"awslogs-create-group": "true",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "ecs"
},
"secretOptions": []
},
"systemControls": []
}
],
"family": "ecs9-test-taskdef",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"networkMode": "awsvpc",
"revision": 2,
"volumes": [],
"status": "ACTIVE",
"requiresAttributes": [
{
"name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
},
{
"name": "ecs.capability.execution-role-awslogs"
},
{
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
},
{
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
},
{
"name": "ecs.capability.task-eni"
},
{
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.29"
}
],
"placementConstraints": [],
"compatibilities": [
"EC2",
"MANAGED_INSTANCES",
"FARGATE"
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "256",
"memory": "512",
"registeredAt": "2026-07-31T05:40:49.834Z",
"registeredBy": "arn:aws:sts::123456789012:assumed-role/xxxxxxxxxx/xxxxxxxxxx",
"tags": []
}
サービス/タスクを新しいリビジョンに切り替える
新しいリビジョンを登録しただけでは、実行中のタスクには反映されません。以下のいずれかで新しいリビジョンを利用開始します。
- ECSサービスで運用している場合: サービスを更新し、新しいリビジョン番号を指定してデプロイする
- 単発のタスク(RunTask)で運用している場合: 次回以降のタスク起動時に新しいリビジョンを指定する
切り替え後、新しいタスクのログがCloudWatch Logsの指定したロググループに出力されていることを確認します。
最後に
今回は、ECS.9の修復手順をご紹介しました。
タスク定義は登録済みのリビジョンを直接変更できないため、修復にはlogConfigurationを設定した新しいリビジョンの登録が必要です。コントロールが評価するのは最新のACTIVEリビジョンなので、logConfigurationを設定した新しいリビジョンを登録すると、次回の評価で検出は解消されます。複数コンテナのタスク定義では、1つでもログ設定が漏れるとFAILEDのままになる点にご注意ください。
ご覧いただきありがとうございました。







