fopnt2016さんの投稿一覧

タスクロールは許可・拒否のルールセットみたいなものなのでそれを作っただけではコンテナには何も起きません。
それをタスク定義で目的のコンテナの設定として紐づけてあげることで、起動されたコンテナが他サービスにアクセスした時エラーにならなくなります。

ですので「コンテナから他のAWSサービスへアクセスするための権限」はタスク定義で設定できます。

細かいことを言えばすでに設定済みのタスクロールの内容変えたらタスクロールでも変えられはするかもですがタスク定義の話ですので。
余談ですがタスクロール／タスク実行ロールは似てますが別物なのでご注意を。

（この回答は参考程度にしてください）

試験問題的には

リクエストは不定期に発生し

をポイントとしていて、（不定期の頻度は不明だが）Fargateでコンテナ化した場合は使われなくても起動しておかなくてはならないし
また、ECSで大量アクセスも想定されるとなるとロードバランサも検討しないといけません。
この点でLambdaが推されてると思います。
試験の話はここまで。

ただ、現実のプロジェクトでは「WebアプリケーションのプログラムはJavaで開発されており」がかなりネックになります。
（「Webアプリケーションシステムを設計している」なのだから、「Javaで開発予定で」の間違いなんですかね）
もしすでに開発が済んでいるアプリケーションならば、Lambdaに対応するコストがいちばん気になる点。
Lambda Web Adapter もありますがなんにせよコンテナ化とコンテナ運用のコストと比較することになると思います。

次にLambdaのメリットは常時起動不要な点にもありますが、Javaは起動が遅いのでアクセスが不定期だとしばしばコールドスタートに陥って応答時間に問題が生まれる可能性もあります。（改良されつづけてはいるものの、今でも無視はできないと思う）
プロビジョニングされた同時実行は要は常時起動なので、コンテナの常時起動を避けたのに本末転倒になる可能性も。
SnapStartはそれ用の修正というか、必要なライブラリだけロードさせておくメソッドの作成が必要になるはず。

15分については他の方も似た様なことをおしゃってますが、ユーザーを15分も待たせるのはWebアプリケーションとして問題がありそうですし、
裏で15分回したいならそこはもうリクエスト受け付けたら別のECSやEC2のバッチサーバー（バッチアプリケーション）に投げてユーザーは待たせない様にすべきです。
というかAPI Gatewayのタイムアウトにひっかかる気もします。

「WebアプリケーションのプログラムはPythonで開発予定で」だったらLambdaから検討するんですけど、
Javaで開発しててLambda使いたいとなると軽量化のためにawsSDK削ったりフレームワーク使うのやめるの検討とかいろいろ気にしなくてはいけないことが多かったというお話でした。