皆さんこんばんわ！
今日も今日とて帰宅時に雨が降るポンコツエンジニアのGONです。
今日は名古屋で線状降水帯が発生して冠水などがあったようですね。
最近よく聞くこの線状降水帯ですが、詳しく知らなかったので調べてみました。
線状降水帯とは、発達した積乱雲が列をなして帯状に並び、
数時間にわたってほぼ同じ場所を通過・停滞することで、激しい雨を長時間降り続けさせる現象のことです。
なにそれ、ゲリラ豪雨じゃないの？と思ったので更に深堀り
ゲリラ豪雨が「点」で短時間に激しく降るのに対し、
線状降水帯は「線」の状態で何時間も同じ場所に激しい雨を降らせ続けます。
ほうほう、なるほど。
いずれにせよ程々にしていただきたいものです。靴びっちょりですわ。
さて、先日まで『PHP』『PostgreSQL』『AWS』の選定理由や、
データベースのセキュリティ実践レクチャー、
ネットワーク設計のポイントなどなど書かせていただきましたが、
皆さんに沢山見ていただけている様でしたので、今回も調子に乗って
**『AWSのログ監視』**について、書かせていただきます！
ログ監視と言えばログをローテーションさせて保存し、
エラーの定義をして、合致したらアラートが上がる様にして、、、、
と全て手作業でやっていた時代はもう過去の話。
今はAWS様に任せておけば画面から数回のクリックで設定終わり、なんてのも大げさな話ではありません。
凄い時代になったものですが、システムの本質はあまり変わっていないわけで、
画面だけ見て理解している気になっていると成長しないよ！
なんて言っていると老害扱いされるのでおとなしくAWSを勉強しています。
CloudTrail：AWSの「誰が何をしたか」
ログ監視の中で最重要な一つです。
例えば、
「誰かが本番環境のS3バケットを削除した」
という事件が起きたとします。
とりあえず自分はADHDなのですぐに疑われるのですが、
必死に否定をしつつCloudTrailを見る様に説明します。
誰が？
→ user/admin@example.com
いつ？
→ 2026-09-08 21:35
何を？
→ DeleteBucket
どこから？
→ 203.xxx.xxx.xxx
どのAWSサービス？
→ S3
といった情報を追跡できます。
つまりCloudTrailは、
「AWS上で誰がどんな操作をしたのか」
を監査するためのログです。
特に監視したいのは、
・IAMユーザー・ロールの変更
・Security Groupの変更
・S3設定の変更
・CloudTrail自体の停止
・KMSキーの操作
・EC2/RDSなどの重要リソース操作
などです。
CloudWatch Logs：アプリやサーバーのログ
CloudTrailが「AWSの操作記録」なのに対して、CloudWatch Logsは、
「アプリやサーバーで何が起きたか」
を見るために使います。
例えばEC2上のアプリなら、
2026-09-08 21:01:23 INFO User login
2026-09-08 21:02:15 WARN Login failed
2026-09-08 21:02:16 WARN Login failed
2026-09-08 21:02:17 WARN Login failed
2026-09-08 21:02:18 ERROR Account locked
のようなログをCloudWatch Logsに集められます。
そして、
「5分間にログイン失敗が100回以上」
のような条件を設定して、アラートを出すこともできます。
VPC Flow Logs：ネットワークを監視する
これは、
「誰と誰が通信したのか」
を見るためのログです。
例えば、
10.0.1.15 → 10.0.2.20 : 443 ACCEPT
10.0.1.15 → 10.0.3.50 : 22 REJECT
のような通信情報を記録できます。
これによって、
・不審なIPとの通信
・大量の通信
・不要なポートへのアクセス
・Security Groupで拒否された通信
などを調査できます。
ただし、Flow Logsは通信内容そのものを記録するものではありません。
通信のメタデータを確認するもの、と考えるとよいです。
WAF Logs：Web攻撃を見る
WebアプリケーションならWAFのログも重要です。
例えば、
IP: 203.xxx.xxx.xxx
Path: /login
Method: POST
Action: BLOCK
Rule: SQLInjection
のような情報から、
「このIPからSQLインジェクション攻撃が来ている」
と判断できます。
WAF + CloudWatch Logs / S3などを組み合わせて、攻撃状況を分析できます。
GuardDuty：ログを「見張る」
ここが一段進んだセキュリティです。
ログを人間が毎日確認するのは現実的ではありません。
そこでGuardDutyなどを使って、
「これは怪しいぞ」
というイベントを検知します。
例えば、
・認証情報の不正利用
・不審なAPI操作
・マルウェアの疑い
・不審なネットワーク通信
・AWS環境に対する攻撃
などを検知できます。
つまり、
CloudTrailなど → GuardDuty → 検出結果
というイメージです。
Security Hub：セキュリティ情報を集約
AWS環境が大きくなると、
GuardDuty
↓
Inspector
↓
Macie
↓
IAM Access Analyzer
↓
その他のセキュリティサービス
と、検出結果がバラバラになります。
Security Hubを使うと、それらをまとめて確認しやすくできます。
そのため実務では、
「ログを集める」ことと「セキュリティ上の問題を検知する」ことを分けて考える
のがポイントです。
じゃあ、実際にどういう構成にする？
例えば企業のAWS環境なら、概念的にはこんな構成です。
AWS環境
│
┌────────┼────────┐
↓ ↓ ↓
CloudTrail WAF VPC Flow Logs
│ │ │
└────────┼────────┘
↓
CloudWatch Logs
│
├──→ アラーム
│
└──→ S3（長期保存）
│
↓
GuardDuty
│
↓
Security Hub
│
↓
通知・インシデント対応
実際にはサービスや規模によって構成は変わります。
皆さんも色々と試行錯誤しながらサービスを組み合わせて最適解を探しているものと思います。
こんなAWSのログ監視構成を試行錯誤して作り上げて
運営している求人マッチングサービスは以下になります。
▼求人マッチングサービス【ヴェテラン】
エンジニアのみなさま、
企業の採用ご担当者のみなさま、
ぜひ、使ってみてくださいっ！！！
「AWSの資格持ってます？」
「ジェフ・ベゾスより髪が薄いって本当？」
など、ご質問やご意見・ツッコミなどいただけますとモチベーションが爆上がりします！
本日もお疲れ様でした。
明日も雨に注意して一生懸命生きていきましょう。
