lunaplus*

AWS Summit Tokyo 2024にて、AWS利用料に関連するセッションがたくさんありました。 CUR(Cost Usage Report)の活用の話のなかで、「CUR2.0がリリースされた」との話を聞いたため、これまで利用していたCUR(Legacy CURと呼ぶらしい…)との違いを確認して、CUR2.0を活用してみようと考えました。 これまでLegacy CURを出力して、Athenaにて集計等を実施しコストの計算を行っていたので、まずはCUR2.0でも同様にAthenaでクエリーができることを確認してみたいと思います。

突然ですが、S3以外のデータソースに対してAthenaからSQLを実行したい場合がありますよね。 前回紹介したAWSサービスの「セキュリティログ」だけでなく、LambdaやFargateといったサービスのログは Clowdwatch Logsに直接出力されていたりします。 もちろん、Kinesis firehoseを経由してS3に保存してからAthenaで検索するという方法もあると思いますが、 Athena Federated Queryのコネクタを利用すると直接、Athenaからクエリが実行できるようになります。

セキュリティインシデントの発生時の対応や各種証跡の保全のためにログを取得することは、これまでも一般的に行われてきました。 特にクラウドでは、セキュリティに関する各種のログが簡単に取得できる各種のサービスやツールが公開されており、企業や個人でも活用されている方は多いと思います。 その一方で、データ量も多く、万一のために取得しているという認識から、なかなか活用に至らないケースも多くあるのではないでしょうか。 昨今では、発見的統制(Detective Control)という言葉も出てきており、セキュリティの問題と潜在的な脅威を見つけ出すことも必要となっていると言われております。

データの集計をする必要が出てきたので、かなり久しぶりにAthenaを使ってみました。 エンジンもVersion 2でPresto 0.217になり、Glueの機能拡張も相まって、以前に利用した際と比べても明らかに使い易くなりました。 ヒストグラムグラフを作る必要があり count() を使った際に思わぬハマりがあったので、記事にしておきます。

AWSを利用したデータ分析の話です。 蓄積されたログをはじめとする各種のデータを傾向分析や障害調査などでちょっと集計するような ことはよくあると思います。”ファイルを集めてきて必要な情報を切り取って平均値を求める” だけなのですが、数万のファイルを集めてその後Grepする？(マジで…)となる状況を 幾度となく見てきました。

オペレーション上の障害でログ調査が必要になり、Athenaを使い始めました。 Athenaを使うとS3上のログファイルに対してブラウザ上でクエリをちょこちょこと書いて検索するだけなので非常に便利です。ただ、現実には毎日や毎時ごとのパーティションを事前に作成する必要があり、この作業が結構忘れがち、、なので「Lambdaからパーティション作成をやってしまおう」という算段です。