Amazon ECS がコンテナのヘルスステータスを CloudWatch メトリクスとして公開

はじめに

2026 年 1 月 30 日、AWS はAmazon ECS（Elastic Container Service）向けの新機能を発表しました。
Container Insights with enhanced observability を通じて、コンテナのヘルスステータスを CloudWatch メトリクスとして自動的に公開する機能です。
この機能は Amazon ECS Container Insights がサポートされる全 AWS リージョンで即座に利用可能となっています。
本記事では、新機能の詳細、従来との違い、実際の使い方、コストや制限事項についてまとめています。

新機能の概要

今回発表された新機能により、ECS コンテナのヘルスステータスを標準的な CloudWatch メトリクスとして監視・アラート設定できるようになりました。

主な特徴

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

• ヘルスステータスメトリクスの自動発行
• 多層的な監視粒度
• CloudWatch 標準機能との統合

ヘルスステータスメトリクスの自動発行

Container Insights with enhanced observability を有効化し、タスク定義でヘルスチェックを設定すると、UnHealthyContainerHealthStatus メトリクスが ECS/ContainerInsights ネームスペースに自動的に発行されます。
メトリクスの値は 0（HEALTHY）か 1（UNHEALTHY）で報告されます。

多層的な監視粒度

メトリクスはクラスター、サービス、タスク、コンテナの4つのディメンション単位で利用可能です。
これにより、全体のトレンドから個別コンテナの詳細まで、粒度に応じた監視が可能になりました。

CloudWatch 標準機能との統合

標準的な CloudWatch メトリクスとして提供されるため、アラーム設定やダッシュボード可視化、Metric Math による集計なども既存の CloudWatch 機能で実現できます。

何が変わったのか

今回発表された新機能により、ECS コンテナヘルスの監視方法が大きく変わりました。
従来の課題と新機能による変化を見ていきましょう。

従来の課題

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

• カスタム実装による監視負担
• アラート設定の複雑さと対応遅延
• 監視粒度の不足

カスタム実装による監視負担

コンテナのヘルスステータスを監視するには、ECS API を直接呼び出し、カスタム CloudWatch メトリクスとして発行する実装が必要でした。
この仕組みを維持するために Lambda 関数やスクリプトのコード作成・メンテナンスが発生し、運用負担になっていました。

アラート設定の複雑さと対応遅延

カスタムメトリクスに基づくアラーム設定では、発行タイミングの調整や false positive の回避には細かいチューニングが必要でした。
そのため、不健全なコンテナへの対応も遅れがちになっていました。

監視粒度の不足

サービス単位やタスク単位での健全性の集計には別途実装が必要で、問題の影響範囲を迅速に特定することが困難でした。

新機能による変化

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

設定のみでメトリクスが自動収集される

Container Insights with enhanced observability を有効化し、タスク定義でヘルスチェックを設定するだけで、UnHealthyContainerHealthStatus メトリクスが自動的に CloudWatch に発行されます。カスタム実装やメンテナンス作業は不要になりました。

標準的な CloudWatch アラームで即時検知

メトリクスが標準的な CloudWatch メトリクスとして提供されるため、通常のアラーム設定で不健全なコンテナを即座に検知し、SNS 通知や Lambda 実行などのアクションをトリガーできます。

クラスターからコンテナまでの段階的な監視

メトリクスはクラスター、サービス、タスク、コンテナの 4 つのディメンション単位で記録されるため、問題の影響範囲を段階的に特定し、適切なスコープで対応できます。

使い方

新機能の使い方を、Container Insights の有効化から実際のアラーム設定までステップバイステップで説明します。

Container Insights with enhanced observability の有効化

1. ECS コンソールでクラスター一覧を開く
2. 対象クラスターを選択
3. 「アクション」 > 「クラスターを更新」 を選択
4. 「モニタリング」セクションで「オブザーバビリティが強化された Container Insights」を選択
5. 「更新」を選択

ヘルスチェックの設定

タスク定義でコンテナのヘルスチェックを設定します。
以下は、Web アプリケーションのヘルスチェック設定例です。

タスク定義

{
  "family": "web-app-task",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "web-app",
      "image": "nginx:latest",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "healthCheck": {
        "command": [
          "CMD-SHELL",
          "curl -f http://localhost/ || exit 1"
        ],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 60
      }
    }
  ]
}

ヘルスチェックのパラメータ

• command: ヘルスチェックコマンド（exit code 0 = 成功、非 0 = 失敗）
• interval: ヘルスチェック実行間隔（秒）
• timeout: タイムアウト時間（秒）
• retries: 失敗と判断するまでのリトライ回数
• startPeriod: コンテナ起動後の猶予期間（秒）

動作確認用サンプル

新機能を実際に試すため、意図的にヘルスチェックが失敗するサンプルを用意します。
以下は、起動後 60 秒経過するとヘルスチェックが失敗するタスク定義の例です。

タスク定義

{
  "family": "unhealthy-demo",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "demo-container",
      "image": "nginx:latest",
      "essential": true,
      "healthCheck": {
        "command": [
          "CMD-SHELL",
          "test -f /tmp/healthy && echo 'healthy' || exit 1"
        ],
        "interval": 10,
        "timeout": 5,
        "retries": 2,
        "startPeriod": 30
      },
      "entryPoint": ["sh", "-c"],
      "command": [
        "touch /tmp/healthy && nginx -g 'daemon off;' & sleep 60 && rm /tmp/healthy && wait"
      ]
    }
  ]
}

このタスク定義では、コンテナが起動後 60 秒で /tmp/healthy ファイルを削除し、ヘルスチェックが失敗するようになります。

タスクの実行

1. ECS コンソールのタスク定義画面ページより「デプロイ」>「タスクの実行」を選択
2. タスク起動後、ヘルスステータスが 正常 → 異常 と遷移することを確認

メトリクスの確認

1. CloudWatch コンソールを開く
2. 左メニューから「メトリクス」→「すべてのメトリクス」を選択
3. ネームスペース「ECS/ContainerInsights」を選択
4. 「UnHealthyContainerHealthStatus」を検索
5. 必要なディメンション（ClusterName、ServiceName 等）でフィルタ
6. グラフで可視化

メトリクスが正しく記録されていることを確認できたら、CloudWatch アラームを設定して不健全なコンテナを自動検知したり、ダッシュボードで可視化することができます。

コストと制限事項

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

料金体系

この機能を利用すると、以下のコストが発生します。

• Container Insights with enhanced observability
• CloudWatch アラーム
• CloudWatch Logs

Container Insights with enhanced observability

Container Insights with enhanced observability は、発行されるメトリクス数に基づいて課金されます。
料金は時間単位で按分され、UnHealthyContainerHealthStatus メトリクスも他のメトリクスと同様に課金対象です。

CloudWatch アラーム

アラームを設定する場合、以下の料金が発生します。

• 標準アラーム: $0.10 / アラーム / 月
• Metric Math を使用するアラーム: $0.30 / アラーム / 月

CloudWatch Logs

EMF ログの取り込み・保存に通常料金が適用されます。

• 取り込み: $0.50 / GB（無料枠：月 5 GB）
• 保存: $0.03 / GB / 月

コスト最適化のポイント

• 本番環境でのみ enhanced observability を有効化し、開発環境では無効化
• 不要なヘルスチェックを削除してメトリクス数を削減
• CloudWatch Logs の保存期間を適切に設定

制限事項

機能面の制限

• Container Insights with enhanced observability の有効化が必須
• ヘルスチェック設定済みコンテナのみがメトリクス対象
• UNKNOWN 状態の詳細は EMF ログ（CloudWatch Logs Insights）での確認が必要
• メトリクスはクラスター、サービス、タスク、コンテナの 4 ディメンションのみ提供

運用上の注意点

• enhanced observability を無効化するとメトリクス発行が停止
• 既存のカスタムヘルス監視との重複に注意（二重課金の可能性）
• ヘルスチェックの false positive に注意（不必要なアラート）
• タスク定義のヘルスチェック変更後は、サービスの更新が必要

まとめ

今回発表された新機能により、コンテナの健全性監視が Container Insights 経由で CloudWatch メトリクスとして自動的に収集されるようになりました。
CloudWatch の標準機能（アラーム、ダッシュボード、Metric Math）をそのまま活用できるため、既存の監視基盤との統合も容易に行えます。
利用にあたっては Container Insights enhanced observability の有効化とヘルスチェック設定が必要となり、メトリクス数に応じた課金が発生するため、特に大規模環境では事前にコスト試算を行うことをお勧めします。
ECS でのコンテナ運用において、健全性監視はサービスの安定性を支える重要な要素です。
本機能を活用して、より効率的で堅牢な監視体制を構築することをお勧めします。

参考リンク