はいどーもー！
エンタープライズ第一本部の宮澤響です！
本記事は電通総研 Advent Calendar 2025 2日目の記事です！
記念すべき1日目である昨日の記事は、米田光佑さんの「AWS Well-Architected のオートメーション（自動化）に触れてみる」でした！
IaCのコードをAWS Well-Architected Frameworkのベストプラクティスに照らして自動的に評価・診断できるツール「Well-Architected IaC Analyzer」の特徴や活用方法が分かりやすく解説されている記事ですので、ぜひご一読ください！
ということで、本記事では、AWSマネジメントコンソール上からAmazon Elastic Container Service（以下、ECS）を操作する際に「おや？」となった3つの事象をご紹介します！
なお、本記事の情報は、2025年11月末時点のものとなりますので、ご承知おきください。
初回のECSクラスター作成時にエラー
事象
過去に一度もECSクラスターを作成したことのないAWSアカウントでECSクラスターの新規作成を実行した際、以下のようなエラーが発生しました。
クラスター xxx の作成中にエラーが発生しました。
Resource handler returned message: "Invalid request provided: CreateCluster Invalid Request: Unable to assume the service linked role. Please verify that the ECS service linked role exists. (Service: AmazonECS; Status Code: 400; Error Code: InvalidParameterException; Request ID: xxx; Proxy: xxx)" (RequestToken: xxx, HandlerErrorCode: InvalidRequest)
エラーメッセージを確認する限り、ECSサービスリンクロールを引き受けられていないようです。
しかし、ECSサービスリンクロールは、ECSクラスター作成時に自動作成されるものです。[参考]
実際、今回も正しい設定値で自動作成されています。
原因
タイミングの問題でした。
ECSクラスターを作成する際、裏ではECSサービスリンクロールを作成する処理やECSクラスターを作成する処理などが並行して実行されます。
そのため、タイミングによってはECSサービスリンクロールの作成完了よりも先にECSクラスターの作成処理が開始されてしまい、ECSサービスリンクロールが存在しないと判定されてしまうことがある、ということのようです。
解決方法
再実行すればOKです。
初回のエラーが発生した直後には既にECSサービスリンクロールが作成されているため、それ以降は特に問題なくECSクラスターを作成できます。
雑感
私が新人研修用のAWSアカウントを16アカウント準備した際、16アカウント全てで上記のエラーに遭遇したため、かなり高い確率で発生するエラーなのではないかと考えられます。
ECSタスクがプロビジョニングと停止を繰り返すもログが出力されていない
事象
下図のように、ECSタスクがプロビジョニングと停止を繰り返すにもかかわらず、CloudWatch Logsにログが一切出力されていない、という事態が発生しました。
なお、デプロイ失敗のエラーとして画面に表示されたメッセージは以下のとおり「サーキットブレーカーが作動したよ」という内容だったため、サーキットブレーカーが止めてくれなければ、永遠にプロビジョニングと停止を繰り返していたと思われます。
miyazawa-test-service-xxx のデプロイ中にエラーが発生しました
Resource handler returned message: "Error occurred during operation 'ECS Deployment Circuit Breaker was triggered'." (RequestToken: xxx, HandlerErrorCode: GeneralServiceException)
原因
ECSタスク定義を作成する際に、awslogs-create-group：trueという設定を削除していたためでした。
awslogs-create-groupにtrueを設定すると、awslogs-groupで指定した名称のロググループが存在しない場合、ロググループを自動作成してくれます。[参考]
今回、私は、最低限の設定で検証したかったため、「削除」ボタンが表示されている（＝必須ではない）項目は削除してしまおう、と安易に削除していました。
なお、ログは出力されなかったものの、前回のステータスの部分にカーソルを重ねてみると、ヒントが隠されていました。
解決方法
以下のいずれかの方法で、無事にECSタスクが起動され、ログも出力されました。
awslogs-create-group：trueを設定するawslogs-groupの値と同名のロググループを事前に作成しておく
雑感
まずはログを確認する、という感覚で生きているため、そもそもログが出力されない本事象では、少し困惑しました。
AWSマネジメントコンソール上のどこにどのような情報が表示されるのかを把握しておくことの重要性を改めて実感しました。
ECSサービス作成画面でALBを新規作成するとエラー
事象
ALB＋ECSの構成で各リソースを作成する場合、ALBやターゲットグループを先に作成してから、ECSサービスを作成するのが一般的です。
しかし、ECSサービス作成画面には、ALBやターゲットグループをその場で新規作成できる欄が存在します。
そのため、そこからの作成を実際に試してみたところ、想定どおりの疎通が確認できない、という事態が発生しました。
なお、構成の概要や設定値は以下のとおりです。
各種リソースの設定が想定どおりであれば、問題なく疎通できるものとします。
- ALBはパブリックサブネットに配置
- ECSタスクはプライベートサブネットに配置
- ALBのSGでは、インターネットからのアクセスを許可
- ECSタスクのSGでは、ALBのSGからのアクセスを許可
原因
ALBに対して、ECSタスクと同一のサブネット配置、同一のSGが設定されてしまうことが原因でした。
つまり、以下のような状態となっていました。
| 想定していた設定 | 実際の設定 | |
|---|---|---|
| サブネット | パブリック | プライベート |
| SG | ALB用 | ECSタスク用 |
解決方法
前述のとおり、ALBやターゲットグループを先に作成してから、ECSサービスを作成するしかなさそうです。
雑感
改めて考えてみたら、確かに画面上にALBのサブネットやSGを設定できる項目がなかったんですよね。
他にも、ALBのヘルスチェックの成功コードなども設定できないようでした。
そのため、「ALBとECSタスクに同一のサブネット配置、同一のSGが設定され、ヘルスチェックの成功コードも200固定でOK」といった前提条件を満たす状況に限り、ECSサービス作成画面からのALB作成が有効なようです。
…そう多くはない状況な気はしますが。笑
おわりに
本記事では、AWSマネジメントコンソール上からECSを操作する際に「おや？」となった3つの事象をご紹介しました。
昨日の記事がIaCに関する内容だったこともあり、イマドキ手動で環境構築すな！IaCで管理せい！というお声が聞こえてきそうですが、実際にIaCのコードを実装する前に、AWSマネジメントコンソール上で手順や設定値を確認することはあると思います。
その際に、たまたま同じような事象に遭遇されましたら、本記事の内容を思い出していただけると幸いです。
さて、電通総研 Advent Calendar 2025 3日目となる明日の記事は、中西陽子さんの「【新機能】Figma Makeの使いどころ」です！
2日連続でAWS関連の記事でしたが、明日は心機一転、AIデザイン生成ツールに関する興味深い記事となります！
お楽しみに！
最後までお読みいただき、本当にありがとうございました！
執筆：@miyazawa.hibiki
レビュー：@yamashita.tsuyoshi
（Shodoで執筆されました）
