🔔 AWS 運用監視の最小構成

CloudTrail + CloudWatch Logs/Alarms + SNS で実現する
運用負荷ゼロの自動監視システム

🏢 ビルのセキュリティシステムで例えると超わかりやすい！

この3つのサービスを組み合わせると「全自動監視システム」が完成！

「誰かがAWSで何かした」→「ログに記録」→「怪しい動きを検知」→「即座に通知」

一度設定すれば 運用負荷ほぼゼロ で、24時間365日監視してくれます。
まさに 「寝ている間も働いてくれるセキュリティガード」 です🛡️

🏢 ビルのセキュリティシステムで理解しよう！

📹

監視カメラ

CloudTrail

ビル内のすべての出入りや行動を24時間録画。「誰が」「いつ」「何をしたか」を漏れなく記録。

💾

映像保管庫

CloudWatch Logs

監視カメラの映像を整理して保管。検索・分析ができる形で長期保存。

🚨

異常検知センサー

CloudWatch Alarms

「深夜に金庫室に入った」など怪しい動きを自動検知。条件に合致したら即アラート。

📱

通報システム

Amazon SNS

異常を検知したら警備員のスマホに即通知。メール・SMS・Slackなど複数手段で通報。

📊 監視の流れを視覚化

👤

誰かがAWSで操作

コンソール/CLI/API

→
📹

CloudTrail

全API操作を記録

→
💾

CloudWatch Logs

ログを保管・検索可能に

→
🚨

CloudWatch Alarms

条件に合致したら発火

→
📱

SNS通知

メール/Slack/SMSで通知

📹

AWS CloudTrail

すべてのAPI操作を記録する「監視カメラ」

🎯 何を記録するの？

AWSで行われた すべてのAPI操作 を記録します。

  • EC2インスタンスの起動・停止
  • S3バケットへのアクセス
  • IAMユーザーの作成・削除
  • セキュリティグループの変更
  • コンソールへのログイン

📝 記録される情報

各操作について以下の情報が記録されます：

  • 誰が： IAMユーザー/ロール名
  • いつ： タイムスタンプ（UTC）
  • 何を： API名（RunInstances等）
  • どこから： 送信元IPアドレス
  • 結果： 成功/失敗

💡 たとえ話で理解

ビルの監視カメラと同じです。

  • 誰がいつビルに入ったか
  • どの部屋に入ったか
  • 何をしたか
  • いつ出ていったか

すべて録画されているので、後から確認できます。

⚙️ 設定のポイント

  • 証跡の作成： 1リージョンまたは全リージョン
  • S3保存： 長期保存用（デフォルト90日）
  • CloudWatch連携： リアルタイム監視に必須
  • データイベント： S3/Lambda操作も記録可能
💾

CloudWatch Logs

ログを保管・検索・フィルタリングする「映像保管庫」

🎯 何ができるの？

CloudTrailのログを 検索・分析可能な形 で保管します。

  • リアルタイムでログを受信
  • キーワード検索が可能
  • メトリクスフィルターで条件検知
  • 長期間の保存（1日〜無期限）

📊 メトリクスフィルターとは

特定のパターンを検知してカウント する機能です。

  • 「rootユーザーログイン」を検知
  • 「IAM変更」をカウント
  • 「特定IPからのアクセス」を監視

これがCloudWatch Alarmsと連携します。

💡 たとえ話で理解

映像保管庫 + AI解析システムのようなもの。

  • 監視カメラの映像を整理して保管
  • 「金庫室」と言えばその映像を検索
  • 「不審な動き」を自動で検出
  • 検出したらカウンターが増える

⚙️ ロググループの構成

  • ロググループ： ログの入れ物（フォルダ）
  • ログストリーム： ログの流れ（ファイル）
  • 保持期間： 1日〜10年or無期限
  • 暗号化： KMSで暗号化推奨
🚨

CloudWatch Alarms

条件に合致したらアラートを発火する「異常検知センサー」

🎯 何ができるの？

メトリクスが 閾値を超えたら自動でアクション を実行します。

  • rootログインが1回以上 → アラート
  • IAM変更が5回以上 → アラート
  • 特定エラーが10回以上 → アラート

📊 アラームの状態

  • OK： 閾値以下、問題なし
  • ALARM： 閾値超過、アクション実行
  • INSUFFICIENT_DATA： データ不足

状態が変わるとSNSに通知が送られます。

💡 たとえ話で理解

ビルの異常検知センサーです。

  • 「深夜0時以降に金庫室に入った」
  • 「1時間に5回以上失敗したログイン」
  • 「許可されていないドア開閉」

条件に合致したら即座にアラーム発報！

⚙️ 設定のポイント

  • 期間： 5分/1分などの評価間隔
  • 統計： 合計/平均/最大/最小
  • 閾値： 何回以上でアラート
  • 評価期間： 何回連続で条件を満たすか
📱

Amazon SNS

複数の宛先に通知を配信する「通報システム」

🎯 何ができるの？

アラームが発火したら 様々な方法で通知 を送ります。

  • 📧 メール送信
  • 📱 SMS送信
  • 💬 Slack/Teams連携
  • 🔧 Lambda起動
  • 📨 SQSキューへ送信

📊 トピックとサブスクリプション

  • トピック： 通知の「チャンネル」
  • サブスクリプション： 通知先の登録

1つのトピックに複数の通知先を登録できるので、メールとSlack両方に通知することも可能。

💡 たとえ話で理解

ビルの通報システムです。

  • 異常を検知したら警備員に電話
  • 同時にビル管理会社にメール
  • 必要なら警察にも通報

1つの異常を複数の関係者に同時通知！

⚙️ Slack連携の方法

  • 方法1： AWS Chatbot（推奨）
  • 方法2： Lambda + Webhook
  • 方法3： メール転送

AWS ChatbotならSNS→Slack連携が超簡単！

🏗️ 完成形アーキテクチャ

👤

AWSユーザー

コンソール/CLI/API操作

⬇️
📹

CloudTrail

全API操作を記録

→
🪣

S3バケット

長期保存（90日〜）

⬇️
💾

CloudWatch Logs

リアルタイム取り込み

⬇️
🔍

メトリクスフィルター

パターン検知・カウント

→
🚨

CloudWatch Alarm

閾値超過で発火

⬇️
📢

SNS Topic

通知を配信

⬇️
📧

Email

担当者へ通知

💬

Slack

チームへ通知

📱

SMS

緊急時の通知

🔍 よくある監視ユースケース

🔐

rootユーザーログイン検知

rootアカウントの使用は緊急時のみ。ログインしたら即座に通知して不正利用を防止。

{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
🛡️

IAMポリシー変更検知

権限の不正変更を検知。管理者以外がIAMを変更したらアラート。

{ ($.eventName = "CreatePolicy") || ($.eventName = "DeletePolicy") || ($.eventName = "PutUserPolicy") }
🚪

セキュリティグループ変更

ファイアウォールルールの変更を検知。意図しないポート開放を防止。

{ ($.eventName = "AuthorizeSecurityGroupIngress") || ($.eventName = "RevokeSecurityGroupIngress") }
🔑

コンソールログイン失敗

ブルートフォース攻撃の検知。連続失敗でアラート。

{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }
🗑️

S3バケット削除検知

重要データの誤削除・不正削除を防止。バケット操作を監視。

{ ($.eventSource = "s3.amazonaws.com") && ($.eventName = "DeleteBucket") }
🌐

VPC変更検知

ネットワーク構成の変更を検知。意図しないルート変更を防止。

{ ($.eventName = "CreateVpc") || ($.eventName = "DeleteVpc") || ($.eventName = "ModifyVpcAttribute") }

🚀 5ステップで構築完了！

1

SNSトピックを作成

まず通知先を作成します。トピック名を決めて、メールアドレスをサブスクライブ。確認メールが届いたら承認をクリック。

⏱️ 所要時間：約3分
2

CloudTrail証跡を作成

マネジメントコンソールからCloudTrailを開き、「証跡の作成」。S3バケット（自動作成）と「CloudWatch Logsへの送信」を有効化。

⏱️ 所要時間：約5分
3

メトリクスフィルターを作成

CloudWatch Logsのロググループを開き、「メトリクスフィルターの作成」。監視したいパターン（rootログインなど）を設定。

⏱️ 所要時間：約5分/フィルター
4

CloudWatch Alarmを作成

メトリクスフィルターから「アラームの作成」。閾値（1回以上など）を設定し、SNSトピックをアクションに指定。

⏱️ 所要時間：約3分/アラーム
5

テスト実行

実際にrootでログインしてみるなど、アラームが発火することを確認。通知が届いたら設定完了！

⏱️ 所要時間：約5分

💰 気になるコストは？

📹 CloudTrail

無料〜

管理イベントは1証跡まで無料。データイベントは$2/10万イベント

💾 CloudWatch Logs

$0.50〜

取り込み$0.50/GB、保存$0.03/GB/月。小規模なら月数百円程度

🚨 CloudWatch Alarms

$0.10〜

標準アラーム$0.10/月/アラーム。10個でも$1/月

📱 Amazon SNS

ほぼ無料

最初の100万リクエスト無料。メール送信も無料枠あり

💡 小規模環境なら月額 $5〜10 程度で24時間365日監視が可能！

📝 CloudFormationテンプレート例（rootログイン検知） 
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Root Login Monitoring Stack'

Parameters:
  NotificationEmail:
    Type: String
    Description: '通知先メールアドレス'

Resources:
  # SNSトピック
  AlertTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: 'security-alerts'
      Subscription:
        - Endpoint: !Ref NotificationEmail
          Protocol: 'email'

  # メトリクスフィルター（rootログイン検知）
  RootLoginMetricFilter:
    Type: AWS::Logs::MetricFilter
    Properties:
      LogGroupName: '/aws/cloudtrail/logs'  # CloudTrailのロググループ名
      FilterPattern: '{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS }'
      MetricTransformations:
        - MetricName: 'RootLoginCount'
          MetricNamespace: 'SecurityMetrics'
          MetricValue: '1'
          DefaultValue: 0

  # CloudWatch Alarm
  RootLoginAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: 'RootLogin-Alert'
      AlarmDescription: 'rootユーザーがログインしました'
      MetricName: 'RootLoginCount'
      Namespace: 'SecurityMetrics'
      Statistic: 'Sum'
      Period: 300  # 5分
      EvaluationPeriods: 1
      Threshold: 1
      ComparisonOperator: 'GreaterThanOrEqualToThreshold'
      TreatMissingData: 'notBreaching'
      AlarmActions:
        - !Ref AlertTopic
⚠️ 設定時の注意点
1. CloudTrailのCloudWatch連携を忘れずに：
CloudTrailを作成するだけではリアルタイム監視ができません。必ず「CloudWatch Logsへの送信」を有効にしてください。

2. SNSサブスクリプションの確認メール：
メール通知を設定すると確認メールが届きます。リンクをクリックして承認しないと通知が届きません。

3. アラームのテストを忘れずに：
設定後は必ず動作確認をしましょう。実際にrootでログインしてアラームが発火するか確認してください。

4. コスト監視も設定推奨：
CloudWatch Logsの取り込み量が多いとコストが増加します。予算アラームも併せて設定しましょう。
💡 運用負荷をさらに下げるコツ
1. AWS Chatbotを使おう：
SNS→Slack連携がGUI操作だけで完了。Lambdaを書く必要なし！チームのSlackチャンネルに直接通知が届く。

2. CloudFormationで管理：
すべての設定をコード化しておけば、他アカウントへの展開も一瞬。上記テンプレートを参考に。

3. AWS Config Rulesも併用：
CloudTrailが「誰が何をしたか」を記録するなら、Configは「今どういう状態か」を監視。両方使うと最強。

4. Security Hubの活用：
複数のセキュリティサービスを一元管理。ベストプラクティスに沿っているか自動チェックしてくれる。

5. 定期的なレビュー：
月に1回は「アラームが多すぎないか」「本当に必要な監視か」を見直そう。アラーム疲れを防ぐ。

🎓 まとめ

🏢 ビルのセキュリティ = AWS監視

一度設定すれば 24時間365日、自動で監視 してくれる
「寝ている間も働くセキュリティガード」の完成！

📹
CloudTrail
全操作を記録
💾
CW Logs
保管・フィルター
🚨
CW Alarms
異常を検知
📱
SNS
即座に通知
⏱️
構築時間

約30分で
構築完了！
💰
月額コスト

小規模なら
$5〜10程度
🛡️
運用負荷

ほぼゼロ！
全自動監視

🎯 まずはrootログイン検知から始めよう！
最小構成から始めて、必要に応じて監視項目を追加していくのがオススメ🚀

Created by SSuzuki1063

AWS SAP Learning Resources