またまたドキュメントをながめていたところ、待望のアップデートを見つけたのでシェアします。 AWS WAFのWebACLトラフィックログをCloudwatch LogsまたはS3に直接出力することが可能になりました！ AWS WAFのWebACLトラフィックログ 従来は以下記事のようにKinesis Data Firehoseを介してCloudWatch LogsまたはS3に出力する必要がありました。 今回のアップデートでAWS WAFから直接CloudWatch Logs、S3に出力可能となりましたので控えめに言って最高のアップデートですね！ 注意点 CloudWatch Logsロググループ名およびS3バケット名はaws-waf-logs-から始まる名前であること Kinesis Data Firehoseも配信ストリーム名でも同じ制約がありましたが、CloudWatch Logs、S3

本日のアップデートで VPC フローログに通信元、通信先の AWS サービス名や通信経路の表示可能になりました。 Amazon VPC Flow Logs now reflects AWS Service name, Traffic Path and Flow Direction さっそく見てみる 以下のログでは後 4 つのフィールドが今回追加されたものになります。 追加されたフィールド 今回追加されたのは以下の 4 フィールドです。 pkt-src-aws-service ソース IP アドレスをもとに AWS サービス名を表示します。表示される値は以下のとおりです。 AMAZON AMAZON_APPFLOW AMAZON_CONNECT API_GATEWAY CHIME_MEETINGS CHIME_VOICECONNECTOR CLOUD9 CLOUDFRONT CODEBUIL

また、クエリの保存は新しい Cloudwatch Logs コンソールでのみ利用が可能です。従来のコンソールを使っている場合は、[Logs] - [Logs group]を開き、上部に表示されているメッセージより新しいコンソールに切り替えてご利用ください。 クエリの保存 Cloudwatch Logs Insights のコンソールを開きます。次にロググループの選択、クエリを入力します。Save ボタンが追加されていますのでクリックします。 クエリの保存画面が表示されますので、任意のクエリ名を入力します。フォルダーは必要に応じて作成してください。対象のサービスや、環境でフォルダー分けしておくと保存されたクエリが整理できて良いかと思います。ロググループや、クエリは既に設定したものが反映されていますので変更がなければ Save をクリックします。 これでクエリの保存は完了です。保存したクエリは

S3 の GuardDuty 的なサービスが本当は欲しいんやけど。無いものは無いので簡易的に異常アクセス数を検出する仕組みを作ってみた。 みなさん、S3 の異常アクセスてどうやって検出していますか？ EC2 への異常アクセスであれば GuardDuty がありますよね。CloudFront, ALB, API Gateway であれば AWS WAF がありますよね。S3 は？ S3 Access Analyzer？ あれは 99% アクセス分析やってくれそうなサービス名ですが、アクセスが来たものを対象に分析するサービスではなく、「アクセスされる危険性があるよー」という分析をしてくれるサービスなので違うんですよ。 AWS CloudTrail Insights？ あー、CloudTrai Insights は API コールのアクティビティを機械学習し、異常な挙動が起きた場合に知らせてくれ

既に Cloudwatch Logs にあるログ分析にはお手軽ですね！ただし、なんでもかんでも分析できるモノではない。 先日のアップデートで CloudWatch Contributor Insights が一般利用可能（GA）になりました。 Amazon CloudWatch Contributor Insights is now generally available CloudWatch Contributor Insights とは 2019年11月にプレビューとして発表された CloudWatch Contributor Insights によって、システムパフォーマンスに影響しているコントリビューターを CloudWatch Logs 上の時系列データから容易に分析することが出来ます。 従来であれば、CloudWatch Logs から Lambda や Kinesis に連携

先日より、Kinesis Data Analytics について学習をはじめています。 今回は、Kinesis Data Analytics のアプリケーション内データストリームで時系列データを扱うにあたって重要な「時間」と「ウィンドウクエリパターン」についての理解を深めていきます。 目次 アプリケーション内データストリームにおける「時間」 どの「時間」を使って分析する？ 2 ウィンドウ戦略 3つのウィンドウクエリ・パターン タンブリングウィンドウ Stagger Windows（ずらしウィンドウ） スライディングウィンドウ まとめ アプリケーション内データストリームにおける「時間」 アプリケーション内データストリームでは、以下 3 タイプの時間に分類されます。正しく分析結果を得るためには、それぞれの時間についての意味を正しく理解しましょう。 引用元：Amazon Kinesis Anal

先日のストリーミングズンドコ記事が面白くて、Kinesis Data Analytics を触ってみたくなりました。 これまで Kinesis Data Analytics を使った経験はないので初心者目線でまとめてみたつもりです。同じように「これからはじめてみよう！」という方の参考にもなるかと思います。 Kinesis Data Analytics とは？ 簡単に言ってしまうと、SQL や Java(Apache Flink) を使ってストリーミングデータに対してリアルタイム分析を行うことが出来るマネージドサービスです。 サービスとしては 2016年8月に GA になっていますが、東京リージョンで利用可能になったのは 2019年1月 ですので、まだ 1年ちょっとですね。 ユースケースとしては「ストリーミング ETL」「継続的メトリック生成」「リアルタイム応答分析」など、幅広いストリーミン