1.1基礎
ECSサービスでCPUまたはメモリ負荷が高いタスクを、個別のTaskIdとコンテナ単位で特定したい。
クラスター全体のタスク数も確認したい。独自の収集・ダッシュボード実装を増やさず、CloudWatchの監視機能を使う。
要求する監視粒度を得るために最も適切なのはどれか。
× 不正解
Container Insightsのenhanced observabilityで、クラスター集計からタスク・コンテナの負荷へ掘り下げる。
詳細解説
正しい対象クラスターでContainer Insights with enhanced observabilityを有効にする
拡張メトリクスとディメンションにより、タスクIDやコンテナまで掘り下げてCPU・メモリを調べられる。
誤り標準のAWS/ECSサービスCPU・メモリメトリクスだけを見る
サービス全体の集計だけでは、個別TaskIdやコンテナの負荷を識別できない。
誤りALBのターゲットヘルスチェックだけを監視する
応答の健全性を確認する機能であり、コンテナごとのCPU・メモリ測定を提供しない。
誤りCloudTrailのRunTaskとStopTaskイベントだけを監視する
タスク操作を監査できても、稼働中のCPU・メモリ使用量は測定できない。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
リンク先のECS拡張メトリクスのディメンションと、既存クラスターの有効化手順を確認する。
参考にした公式資料
確認できる内容
必要なTaskId・コンテナ単位のメトリクスと、既存クラスターのcontainerInsights=enhanced設定を説明できる。
理解のポイント
- Container Insights
- ECSタスク
- クラスター
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
監視粒度を先に決める
サービスの集計値が正常でも、一部のタスクやコンテナに負荷が集中する場合がある。拡張監視のTaskIdなどのディメンションを使い、対象を識別してCPU・メモリを見る。集計値だけで個別タスクの状態を推測しない。
既存クラスターにも設定する
新規クラスター向けのアカウント設定を変更しただけで、既存クラスターがすべて切り替わるわけではない。対象クラスターのcontainerInsightsをenhancedに更新し、ECS/ContainerInsightsの対象メトリクスが出ていることを確認する。
問題IDAWS-SOA-013
確認環境AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
最終技術確認2026-10-03
誤り・権利侵害を報告