オートスケールを組んだ際に気になる共有ストレージについて書きました。ついて書きたいと思います。おけるログ出力ECSはつまるところDockerコンテナなので、スケールやデプロイのたびに、破棄と生成が行われます。前回説明した通り、永続ボリュームを用意しなければ、コンテナ内で生成した各種ファイルはデプロイのたびに破棄されてしまいます。そのため、ECSコンテナ内で生成されるログも、永続ボリューム等の非揮発性のストレージに保持をする必要があります。今回は大きく分けて3つの方法を紹介したいと思います。連携も簡単にできるデメリット素のCloudWatchLogsだけでは、内容を確認するのにかなり手間がかかるログが1行ずつ出力されるので、情報を追い辛い。パラメータを追加するの2つの作業で終わりです。超お手軽なので、私は特別な理由がなければこちらの方法を利用しています。コストが割高との声をよく聞きますが、自前のログ集約機構をメンテナンスしたりするコストを考えると、意外とトータルのコストはそこまで安くならないのでは?と思ったりしています。ランニングコストを固定化したい等の要件がある場合は、自前のクラスタを組んでしまう方が良いでしょうね。ドライバの他にも、下記の通りかなりの量のログドライバが存在しています。fluentdログドライバであれば、fluentdのクラスタ等を自前で用意して、そこへアプリケーションログを送信して、煮るなり焼くなりするような流れになります。使用できないようなので、注意が必要でしょう。要約した結果のみ記載しておきます。