【AWSのログ周りを整理する】全体像 ── 4段に分けて 位置づける

Transcript

1. 2026年9月 AWSのログ周りを整理する 第1回 全体像 ── 4段に分けて位置づける 赤神青空
2. ▪全6回のうち、今回は第1回 このシリーズの地図 第1回 全体像 第2回 出す 第3回 運ぶ 第4回 貯める 第5回 調べる 第6回 選び方 今ココ はじめに 4段に分けて位置づける ログはどこで生まれるか 発生源と置き場のあいだ コストの大半はここで決まる 貯めたログに問い合わせる 結局どう決めるのか 2/9
3. ▪ひとつだけに絞ります 今日持ち帰ってほしいこと サービス名を覚えるのではなく、 4つの段のどこにいるかで位置づける。 名前で覚えると 新しい名前が出るたびに覚え直しになる。 位置で覚えると 新しい名前もどの段の話かで置ける。 覚える対象は、サービスではなく段のほうです。 今ココ はじめに 3/9
4. ▪名前が多いことが原因ではありません なぜこんがらがるのか 全部をまとめて「ログのサービス」と呼んでいるが、実際には役割が違う。 同じ「ログ」で4種類のデータを指している 出す側と貯める側と調べる側が混ざっている サービスによって課金の軸がまったく違う AWSが毎年名前と機能を足してくる 今ココ はじめに 4/9
5. ▪どの段にいるかで役割が決まる ログ関連サービスの全体像 出す 運ぶ CloudTrail API操作の監査 VPC Flow Logs 通信の記録 貯める サブスクリプション フィルタ 調べる CloudWatch Logs 標準 / 低頻度 直近の調査 CloudWatch Pipelines 変換‧OCSF化 Amazon S S Tables 統合も アクセスログ Athena ELB‧CloudFront‧S AWS WAF 検査したリクエスト アプリログ エージェント / OTLP Log Analytics S にSQLを投げる Data Firehose バッファして配信 OpenSearch 検索‧ダッシュボード OpenSearch Dashboards Kinesis Data Streams ⾃前で処理する場合 Security Lake 常時監視 OCSFで集約 ELB や CloudFront は S へ直接出せるので「運ぶ」段を⾶ばせる この資料で扱うサービスを4段に配置したもの 今ココ 全体像 5/9
6. ▪まずここを分けないと話が混ざる 「ログ」と呼んでいる4つ CloudWatch はこの4つを全部扱うので、話が混ざる最大の原因になる。 01 02 03 04 何が起きたかのテキスト記 録 数値の時系列。集計済み 1リクエストがたどった経路 起きたことの通知。配送が 主役 ログ 今ココ 全体像 メトリクス トレース イベント 6/9
7. ▪この表が今日の地図になります 4段と代表的なサービス 出す 運ぶ 貯める 調べる 発生源で記録する 転送・変換する 保管する 問い合わせる 今ココ 全体像 CloudTrail / VPC Flow Logs サブスクリプションフィルタ / Firehose CloudWatch Logs / S3 / OpenSearch Log Analytics / Athena 7/9
8. ▪先にスコープを切っておきます 今回扱わないもの ログ周りではあるものの、今回は触れないものを先に挙げておきます。 Config・GuardDuty・Security Hub（検知系） OpenSearch Ingestion・EventBridge Pipes Glue データカタログ（Athenaのスキーマ置き場） QuickSight・Managed Grafana（可視化） 今ココ 全体像 8/9
9. ▪第1回で覚えて帰るのは3つ まとめ 01 4段で位置づける 出す・運ぶ・貯める・調べる。新しい名前もここに置く。 02 「ログ」は4種類ある ログ・メトリクス・トレース・イベントが混ざっている。 03 覚えるのは段のほう サービス名ではなく、どの段の話かで置く。 次回は「出す」── ログがどこで生まれるかを見ていきます 今ココ おわりに 9/9