計算上15%のサイズに圧縮される前提となっていたようです。100%だと3.3USDですね。圧縮についてしらべる推測15%と記載がありましたが、実際どの程度圧縮されるのか気になりました。それをS3へ転送した場合どうなるのか。Streamで、S3へ転送するというパターンを取ってみたいと思います。Logsへ転送するシーンを想定します。いちおうログをS3まで転送する部分のCloudFormationテンプレートを作っておきました。Apacheはインストールしません。その代わりに、Apacheアクセスログのような形式でダミーログを作成してくれる以下を利用させて頂きました。やってみるアクセスログを生成EC2にセッションマネージャーでリモートアクセスし、apache-loggenをインストールして475,000行のアクセスログを生成します。access_log101MBのファイルが作成されましたね。Logsに転送されているか見てみましょう配信されていますね。本物のログみたいです。次に、ログのサイズを確認してみましょう。保管サイズを確認出来るCLIコマンドが2つあります。describe-log-streamsでは保管サイズは今は取得出来ないみたいです。describe-log-groupsで確認する必要があるようです。affecte確認してみましょう。]}おや、どちらもサイズが確認出来ないですね。ドキュメントに記載が見当たらなかったのですが、どうやらサイズの反映はかなり時間差がかかるみたいです。私が確認した時は、17時間後くらい経過してサイズが取得出来るようになりました。]}23MiBですね。圧縮率80%くらいでした。S3の確認S3にも転送されていますね。サイズを確認してみましょう。MiB合計サイズは11.3MiBになっていました。えっ?さらに圧縮されているのだろうか。それとも全てのログレコードが転送されていないのか。ダウンロードして解凍し、サイズを確認してみましょう。iwasa-firehose-deliverystream-httpdaccess-1-2021-09-16-11-42-10-f905b492-dd55-4895-9ae2-7824d7dcaae6元のログデータよりかなり大きいですね、サイズが。S3に格納されたログファイルは生データの状態ではなくて、加工されたJson形式になっており、ある属性に生データが全部入っています。そのせいで、オリジンデータよりサイズが増えているようです。いうフォーマットになっているのかは以前こちらの記事で少しまとめましたので宜しければ見てみてください。Jsonファイルの中のmessageキーワードが何件あるのか調べてみました。だいたいのログレコード件数がわかるはずです。48961だいたい475,000件ちょっとなので、ログレコードが転送されておらず、サイズが削減されているわけではなさそうですね。さいごにというわけで序盤の計算はApacheダミーアクセスログで試したところ以下のようになりました。MiBCalculatorで15%くらいの圧縮率で計算されていますが、大きく乖離はしてなさそうですね。S3へ転送する場合はその圧縮率程度のサイズはキープはされそうなので、S3側の見積もりを行う際にも圧縮率を考慮するのが良さそうです。ログの内容によって圧縮率というのは上下するので、一概には言えないと思いますが。ひとつの参考になるかなと思いました。送信ストリーム内で圧縮を使用する必要はありません。レベル6で圧縮されているようです。圧縮率を検証されている方がいらっしゃったので参考にさせて頂きましたがレベル6だと80%強の圧縮率だったようですので、たしかに近い値が出ていますね。LogsからS3へ無圧縮で転送してる場合でも半分程度のサイズになる部分はちょっとわかりませんでした。ディープダイブした後にこちらの世界に返ってこれた人がいらっしゃれば、このあたりの秘密を教えてもらえると嬉しいです。