普段の開発や運用でメールボックスを常に監視するのは大変ですよね。そこで今回は、エンジニアの必須ツールである**「Slack」にアラートを直接飛ばす仕組み**にアップグレードします！

ただ通知先を変えるだけではありません。今回はAWSアーキテクチャの醍醐味である**「SQS（待ち行列）」と「AWS Lambda（サーバーレスプログラム）」**を間に挟みます。 もし世界中から同時にサイバー攻撃を受けても、システムがパンクすることなく確実に通知を届けてくれる「疎結合（そけつごう）アーキテクチャ」を、実質0円で体験してみましょう！

今回の完成イメージ

1. CloudWatchが攻撃を検知し、SNS（通知ハブ）へ発報。
2. SNSが**「SQS（キュー）」**にメッセージをポンッと入れる。
3. SQSにデータが入ったのをキッカケに、**「Lambda（Pythonプログラム）」**が自動起動。
4. LambdaがSlackに「 攻撃検知！」とメッセージを送信！

Slackで「通知受け取り用のURL」を発行する

まずは、Slack側に「ここ宛にメッセージを送ってね」という専用の窓口（Webhook URL）を作ります。

1. パソコンのブラウザで Slack API の管理画面 (https://api.slack.com/apps) にアクセスし、右上の 「Create New App」 をクリックします。

1. 「From scratch」 を選びます。

1. App Name に WP-Security-Bot など好きな名前を入力し、通知を送りたいワークスペースを選択して 「Create App」 を押します。

1. 左メニューから 「Incoming Webhooks」 をクリックし、右上のスイッチを 「On」 にします。

1. 画面下のほうにある 「Add New Webhook to Workspace」 をクリックします。

通知を飛ばしたいチャンネル（例：#general や #alert など）を選んで「許可する」を押します。

Webhook URL （https://hooks.slack.com/services/...）が発行されるので、「Copy」ボタンを押してメモ帳などに控えておいてください。

SNSトピック（通知ハブ）を作成する

まずは、CloudWatchからの警報を受け取る「ハブ」を作成します。

1. AWSマネジメントコンソールで 「SNS」 と検索し、「Amazon SNS」を開きます。」

1. 左側のメニューから 「トピック」 を選び、右上の 「トピックの作成」 をクリックします。

1. タイプ: 必ず 「スタンダード」 を選択します。（※FIFOを選ぶとCloudWatchから直接送れなくなります）

画面一番下の 「トピックの作成」 をクリックします。

メトリクスフィルター（攻撃のカウント器）を作成する

次に、Lightsailから送られてきているアクセスログの中から、「攻撃とみなす特定の文字（例：wp-login.php）」を見つけ出してカウントする設定を行います。

1. AWSコンソールで 「CloudWatch」 を開きます。

左メニューの「ログ」から 「ロググループ」 を選び、Lightsailのアクセスログ（例：lightsail-wp-access-log）をクリックします。

1. 「メトリクスフィルター」 タブを開き、「メトリクスフィルターを作成」 をクリックします。

1. フィルターパターン: ログの中から探したいキーワードを入力します。
   • 例："wp-admin" （※ダブルクォーテーションで囲むと確実です）

できる限り、ログの中からパターンをテストすることをおすすめします

1. 「次へ」をクリックし、フィルターの詳細を以下のように設定します。
   • フィルター名: Detect-WP-Login-Attack
   • メトリクス名前空間: WordPressSecurity （※新しいカテゴリ名を作ります）
   • メトリクス名: LoginAccessCount
   • メトリクス値: 1 （※キーワードを1回見つけるごとに「1」カウントするという意味です）

1. 「メトリクスフィルターを作成」 をクリックします。

CloudWatchアラーム（警報装置）を作成する

最後に、ステップ2で作ったカウント器が「規定の回数」を超えたら、ステップ1で作ったSNSに発報する設定を行います。ここが一番繋ぎ忘れがちなポイントです！

1. いま作成したメトリクスフィルターの画面右上に表示される、「アラームを作成」 というボタンをクリックします。

1. 【メトリクスと条件の指定】
   • 統計: 合計 (Sum) に変更します。
   • 期間: 1分 または 5分 に設定します。（テスト時は1分がおすすめです）
   • 条件: 静的 (Static) ＞ 以上 (Greater/Equal) を選びます。
   • しきい値: 5 と入力します。（※「1分間に5回アクセスがあったら」という意味になります）

1. 【アクションの設定（超重要！）】
   • アラーム状態トリガー: アラーム状態 のままにします。
   • 通知の送信先: 既存のSNSトピックを選択 を選びます。
   • その下の「通知の送信先」の検索窓をクリックし、ステップ1で作った wp-attack-alert-topic を選択します！

1. 「次へ」をクリックします。
2. 【名前と説明の追加】
   • アラーム名: WP-Login-Attack-Alarm などと入力し、「次へ」をクリックします。

1. 最後に設定内容を確認し、画面一番下の 「アラームの作成」 をクリックします。

動作確認（テスト）のやり方

ここまで設定できたら、CloudWatchとSNSが本当に繋がっているかテストしてみましょう。

1. ご自身のWordPressのログインURL（例：https://polepolelife.com/wp-login.php）をブラウザで開きます。
2. F5キー（更新）を5〜6回ほど、パパパッと連打します。
3. CloudWatchの「すべてのアラーム」画面を開いて数分待ちます。
4. アラームの状態が緑色の「OK」から、赤色の「アラーム状態」 に変われば大成功です！

アラーム状態になった瞬間、設定したSNSトピックに向けて裏側でメッセージが飛んでいます。このSNSにSQSを連携（サブスクライブ）させておけば、見事なピタゴラスイッチの完成です。

メッセージの待合室「SQS」を作成する

大量の通知が来てもパンクしないように、メッセージを一時的に貯めておく「キュー（SQS）」を作ります。

1. AWSマネジメントコンソールで 「SQS」 と検索し、「Simple Queue Service」を開きます。

1. 右上の 「キューを作成」 をクリックします。

タイプは 「標準」 のままでOKです。

名前 に wp-alert-queue と入力します。

その他の設定はすべて初期状態のままで、一番下の 「キューの作成」 をクリックします。

超重要：SNS（第3回で作ったアラーム）とSQSを繋ぐ

いま作ったSQSの画面に「SNS サブスクリプション」というタブがあります。

「Amazon SNS トピックをサブスクライブ」 をクリックします。

SNSトピック（例：wp-alert-topic）を選んで「保存」を押します。 (※これだけで、CloudWatchのアラームが鳴ると、自動的にこのSQSにメッセージが届くようになります！) SNSトピックなかったら作っておいてください

設定終了したら保存します

自動実行プログラム「AWS Lambda」を作成する

SQSにメッセージが届いたら、それを拾ってSlackに転送するPythonプログラムを作ります。

1. AWSの検索バーで 「Lambda」 と検索して開きます。

1. 右上の 「関数の作成」 をクリックします。

1. 以下のように設定します。
   • 関数名: NotifyToSlackPolePole
   • ランタイム: Python 3.12 （または最新のPython）
   • アーキテクチャ: x86_64

1. 右下の 「関数の作成」 をクリックします。

環境変数（Slack URL）の設定

コードの中に直接URLを書くのはセキュリティ上良くないため、環境変数に登録します。

1. Lambdaの画面中段にある 「設定」 タブ ＞ 左側の 「環境変数」 ＞ 「編集」 をクリック。
2. 「環境変数の追加」 を押し、以下を入力して保存します。
   • キー：SLACK_WEBHOOK_URL
   • 値：SlackのWebhook URL

Pythonコードの貼り付け

「コード」 タブに戻り、元々書かれているコードをすべて消して、以下のコードを貼り付けます。

import json
import urllib.request
import os
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

SLACK_WEBHOOK_URL = os.environ['SLACK_WEBHOOK_URL']

def lambda_handler(event, context):
    try:
        # SQSから送られてきたメッセージを処理
        for record in event['Records']:
            # SNSからSQSに渡された中身（body）を取り出す
            sns_message = json.loads(record['body'])
            alarm_info = json.loads(sns_message['Message'])
            
            # アラームの名前や理由を取得
            alarm_name = alarm_info.get('AlarmName', '不明なアラーム')
            alarm_desc = alarm_info.get('NewStateReason', '詳細なし')
            
            # Slackに送るメッセージのデザイン
            slack_payload = {
                "text": f"<img src="https://s.w.org/images/core/emoji/16.0.1/72x72/1f6a8.png" alt="🚨" class="wp-smiley" style="height: 1em; max-height: 1em;" /> *WordPress セキュリティ警告*\n*アラーム名:* {alarm_name}\n*詳細:* {alarm_desc}\n至急、AWS CloudWatchを確認してください！",
                "icon_emoji": ":rotating_light:"
            }
            
            # Slackへ送信
            req = urllib.request.Request(
                SLACK_WEBHOOK_URL, 
                data=json.dumps(slack_payload).encode('utf-8'), 
                headers={'Content-Type': 'application/json'}
            )
            urllib.request.urlopen(req)
            logger.info("Slack通知に成功しました。")

        return {'statusCode': 200, 'body': 'Success'}

    except Exception as e:
        logger.error(f"エラーが発生しました: {e}")
        return {'statusCode': 500, 'body': 'Error'}

import json
import urllib.request
import os
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

SLACK_WEBHOOK_URL = os.environ['SLACK_WEBHOOK_URL']

def lambda_handler(event, context):
    try:
        # SQSから送られてきたメッセージを処理
        for record in event['Records']:
            # SNSからSQSに渡された中身（body）を取り出す
            sns_message = json.loads(record['body'])
            alarm_info = json.loads(sns_message['Message'])
            
            # アラームの名前や理由を取得
            alarm_name = alarm_info.get('AlarmName', '不明なアラーム')
            alarm_desc = alarm_info.get('NewStateReason', '詳細なし')
            
            # Slackに送るメッセージのデザイン
            slack_payload = {
                "text": f"🚨 *WordPress セキュリティ警告*\n*アラーム名:* {alarm_name}\n*詳細:* {alarm_desc}\n至急、AWS CloudWatchを確認してください！",
                "icon_emoji": ":rotating_light:"
            }
            
            # Slackへ送信
            req = urllib.request.Request(
                SLACK_WEBHOOK_URL, 
                data=json.dumps(slack_payload).encode('utf-8'), 
                headers={'Content-Type': 'application/json'}
            )
            urllib.request.urlopen(req)
            logger.info("Slack通知に成功しました。")

        return {'statusCode': 200, 'body': 'Success'}

    except Exception as e:
        logger.error(f"エラーが発生しました: {e}")
        return {'statusCode': 500, 'body': 'Error'}

貼り付けたら、ファイル上部の 「Deploy」 ボタンを押してコードを保存します。

Lambdaに「SQSを読み取る権限」を渡す

LambdaがSQSの中身を見るためには「許可証（IAMロール）」が必要です。

1. Lambdaの 「設定」 タブ ＞ 左側の 「アクセス権限」 を開きます。
2. 実行ロールの青いリンク（NotifyToSlack-role-xxxx のような名前）をクリックすると、IAMの画面が開きます。

1. 「許可を追加」 ＞

「ポリシーをアタッチ」 をクリックします。

1. 検索窓で AWSLambdaSQSQueueExecutionRole と検索し、チェックを入れて 「許可を追加」 を押します。 (※これでLambdaがSQSを読み取れるようになりました！)

SQSとLambdaを合体させる！

最後の仕上げです。「SQSにデータが入ったらLambdaを動かす」というトリガーを設定します。

1. Lambdaの画面に戻り、上部の 「＋ トリガーを追加」 をクリックします。

SQSキューの入力欄をクリックし、ステップ2で作った wp-alert-queue を選びます。

右下の 「追加」 をクリックします

完了！実際に攻撃テストをしてみよう

お疲れ様でした！これでAWS内の美しい連携システムが完成しました。 実際に動くかテストしてみましょう。

【テストの手順】

1. 自分のブログのログイン画面（https://あなたのドメイン/wp-login.php）をブラウザで開きます。
2. F5キー（更新）を5〜6回ほど、連続して連打します。
3. そのまま5分ほど待ちます。

設定したSlackのチャンネルに、「 WordPress セキュリティ警告」 というメッセージがピコン！と通知されれば大成功です！！

まとめ

今回は、直接Lambdaを動かすのではなく、あえて間に「SQS」を挟みました。 これにより、仮に何万回という凄まじい攻撃を受けてアラームが鳴りやまない状態になっても、SQSがバッファ（緩衝材）となり、システムを落とすことなく順番に処理してくれます。

これぞクラウドの醍醐味！実質0円でこのエンタープライズ品質のシステムが組めるのは本当に楽しいですね。 次回はいよいよ、この通知システムをさらに進化させ、**「攻撃者のIPアドレスをCloudflareのWAFで全自動ブロックする仕組み」**に挑戦します！

LightsailのWordPressから始まり、CloudWatchでのログ集約、FirehoseとS3を使った永久保存、そしてログイン画面への攻撃検知アラームと、これまで3回にわたってAWSの本格的な「ログ分析・監視基盤」を自作してきました。

「AWSでこれだけ色々なサービスを組み合わせたら、毎月数千円くらい請求が来るのでは…？」と不安に思うかもしれません。

しかし結論から言うと、月間数万PV以下の個人ブログであれば、この超本格的なデータパイプラインは**「月額ほぼ0円」**で運用可能です！今回はその驚きのコスト内訳と、S3に保存したログを「Amazon Athena」を使って一瞬で分析する方法をご紹介します。

なぜ0円？自作ログ基盤のコストパフォーマンス検証

今回のシステムで使っているAWSサービス群の「料金の仕組み」と、月間数千PVのブログを想定した「実際の請求額」をまとめました。（※東京リージョンの料金です）

ご覧の通り、AWSには「Always Free（永久無料枠）」が豊富に用意されており、さらに従量課金のサービス（S3やFirehoseなど）も、個人ブログのデータ量（月に数MB〜数十MB程度）であれば**「1円未満のため請求なし（$0.00）」**となります。

サーバーの負荷を一切上げずに、これだけのエンタープライズ級の環境を無料で維持できるのが、自作の最大のメリットです！

全体像

簡単にではありますが、下記の図で全体像がわかると思います

lightsail のログをcloudwatch で吐き出して、Firehorse経由でS３におくり、Athena で分析という形です。SNSの通知はオプションですのでまたの機会があれば、別の記事で書こうと思います

Amazon AthenaでS3のログをSQL分析してみよう！

S3にログを永久保存できたのは良いですが、S3の画面から直接ファイルの中身を見ることはできません。（ダウンロードして解凍する必要があります）

そこで活躍するのが**「Amazon Athena（アテナ）」**です。Athenaを使えば、S3に置いてある大量のログファイルに対して、データベースを構築することなく直接「SQL」を打ち込んで検索・分析ができます。

ステップ1：Athenaの「結果保存用フォルダ」を作る

Athenaを使うには、まず「検索結果を一時的に保存するS3フォルダ」を指定する必要があります。

1. AWSマネジメントコンソールで**「S3」**を開きます。

1. 前回作ったバケット（例：polepolelife-logs）を開きます。

1. **「フォルダの作成」**をクリックし、名前に athena-results と入力して作成します。

フォルダを作成します

ステップ2：Athenaを開いて初期設定をする

1. 検索バーで**「Athena」**と検索して開きます。

1. 左メニューの「クエリエディタ」を開きます。

1. 画面の上部に「クエリ結果の場所を設定してください」という青い警告文が出るので、**「設定を編集」**をクリックします。

クエリ設定のタブで　クエリ結果の場所と暗号化を管理する　があるので、そこでBrowse S3 を押して先程のS3のロケーションをクエリ結果として指定します

下記の画面で「管理」をクリック

Browse S3　で検索結果の場所を指定する

先程作成した　Athena-result　を指定します

ログを読み込む「テーブル（表）」を作成する

S3にあるテキストデータをAthenaに「これはアクセスログだよ」と認識させるための設定（テーブル作成）を行います。

クエリエディタの広くて白い入力欄に、以下のSQL文をすべてコピーして貼り付け、右上の**「実行」**ボタンを押してください。

CREATE EXTERNAL TABLE IF NOT EXISTS wp_access_logs (
  client_ip string,
  client_id string,
  user_id string,
  request_date string,
  request string,
  status_code string,
  object_size string,
  referer string,
  user_agent string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
  "input.regex" = "^([^ ]+) ([^ ]+) ([^ ]+) \\[([^\\]]+)\\] \"([^\"]+)\" ([0-9]+) ([0-9]+|-) \"([^\"]*)\" \"([^\"]*)\".*"
)
LOCATION 's3://polepolelife-logs/ athena-results/';

CREATE EXTERNAL TABLE IF NOT EXISTS wp_access_logs (
  client_ip string,
  client_id string,
  user_id string,
  request_date string,
  request string,
  status_code string,
  object_size string,
  referer string,
  user_agent string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
  "input.regex" = "^([^ ]+) ([^ ]+) ([^ ]+) \\[([^\\]]+)\\] \"([^\"]+)\" ([0-9]+) ([0-9]+|-) \"([^\"]*)\" \"([^\"]*)\".*"
)
LOCATION 's3://polepolelife-logs/ athena-results/';

※注意：一番最後の LOCATION の部分は、前回自分が作ったS3のパスに書き換えてください。

例：s3://yourblog-logs-2026/ （必ず最後に / をつけてください）

左側の「テーブル」という欄に wp_access_logs が表示されれば準備完了です！

Firehoseの設定変更

CloudWatch Logsは、データをFirehoseに渡す際、通信量を節約するために**「全体をGZIPでガチガチに圧縮した上で、AWS特有の複雑なJSON形式で包んで」**送っています。

そのため、今のS3には「WordPressの綺麗なアクセスログ」ではなく、「解凍できない謎の暗号データ（バイナリ）」が保存されてしまっています。Athenaはそれをテキストとして読もうとして「なんだこれ？読めないから結果0件にしとこう」と無視してしまっている状態です。

Firehoseの「自動解凍＆抽出機能」をオンにする！

わざわざAthena側で難しいSQL（UNNESTなど）をこねくり回す必要はありません。AWSが最近追加した神機能を使って、Firehoseに「S3に保存する前に解凍して、中身のログだけを綺麗に取り出して！」と指示するだけで解決します。

Firehoseの設定を変更する

1. AWSマネジメントコンソールで 「Data Firehose」 を開きます

1. 対象のストリーム（wp-log-delivery-stream）をクリックします。

1. 「設定 (Configuration)」 タブを開きます。

1. 下にスクロールし 「レコードの変換と形式変換 (Transform and convert records)」 の右上にある 「編集」 をクリックします。

1. 以下の2つのチェックを「オン」にします。
   • Amazon CloudWatch Logsからのソースレコードを解凍する: 解凍をオンにする を選択

1. ログイベントからメッセージフィールドのみを抽出する: メッセージ抽出をオンにする を選択 (※この2つ目のチェックが超重要です！AWS特有のJSONの殻を破り捨てて、純粋なApacheログだけをS3に保存してくれます)

「変更の保存」をクリックします。

実際にSQLで分析してみよう！

これでS3のログを自由に分析できるようになりました。クエリエディタの「＋」ボタンを押して新しいタブを開き、いくつか便利なSQLを試してみましょう！

例1：直近のアクセスを10件だけ見てみる

SELECT * FROM wp_access_logs LIMIT 10;

SELECT * FROM wp_access_logs LIMIT 10;

これを実行すると、Excelのような綺麗な表形式でアクセスログが表示されます！

例2：どのページに一番アクセスが来ているかランキングを出す

SELECT request, count(*) as count 
FROM wp_access_logs 
GROUP BY request 
ORDER BY count DESC 
LIMIT 10;

SELECT request, count(*) as count 
FROM wp_access_logs 
GROUP BY request 
ORDER BY count DESC 
LIMIT 10;

例3：不審なアクセス（404エラー）を出しているIPアドレスを特定する

SELECT client_ip, count(*) as error_count 
FROM wp_access_logs 
WHERE status_code = '404' 
GROUP BY client_ip 
ORDER BY error_count DESC 
LIMIT 10;

SELECT client_ip, count(*) as error_count 
FROM wp_access_logs 
WHERE status_code = '404' 
GROUP BY client_ip 
ORDER BY error_count DESC 
LIMIT 10;

このように、Athenaを使えば「いつ・誰が・どこにアクセスして・どんなエラーが出たのか」を一瞬で丸裸にできます！

まとめ：自分だけの最強ログ基盤が完成！

全4回にわたって構築してきた「AWSサーバーログ分析基盤」、いかがだったでしょうか。

1. CloudWatch でサーバーを見に行かずにログを確認し
2. Firehose + S3 で容量を気にせず実質0円で永久保存し
3. EventBridge(CloudWatchアラーム) + SNS で攻撃を即座に検知し
4. Athena で好きな時にビッグデータ分析ができる

大企業が数百万円かけて構築するようなシステムを、個人ブログの規模なら**「月額0円」**で運用できる。これこそがクラウド（AWS）の最大の魅力であり、エンジニアとしての大きな武器になります。

ぜひご自身のブログでも、この記事を参考に最強の監視基盤を作ってみてください！

しかし、CloudWatch Logsはそのまま放置するとデータが溜まり続け、無料枠（5GB/月）を超えると課金されてしまいます。 そこで今回は、**「CloudWatchに届いたログを、自動的にAmazon S3（超格安のストレージ）へ移動させて永久保存する仕組み」**を作ります！

これを構築すれば、どれだけログが溜まっても**維持費は月に数円〜数十円（月間数万PVなら実質0円レベル）**に抑えられます。 今回も初心者向けに、画面のクリック手順まで詳しく解説していきます！

今回の完成イメージ

1. WordPressのログが CloudWatch Logs に届く
2. Amazon Data Firehose (旧: Kinesis Data Firehose) がログをキャッチする
3. Amazon S3 に自動でファイルとして整理・保存される！

簡単に言えば下記のようになります

豆知識： 以前は「Kinesis Data Firehose」という名前でしたが、最近AWSのアップデートで**「Amazon Data Firehose」**に名前が変わりました。機能は同じなので安心してくださいね。

ログの「最終保管庫（S3バケット）」を作る

まずは、ログを永久保存するための箱（S3バケット）を用意します。

1. AWSマネジメントコンソールの検索バーで**「S3」**と検索して開きます。

1. 右上の**「バケットを作成」**ボタンをクリックします。

1. バケット名に yourblog-logs-2026 など、好きな名前を入れます。（※世界中で自分だけのユニークな名前にする必要があります）

1. **「パブリックアクセスをすべてブロック」**にチェックが入っていることを確認します。（ログという機密情報なので、絶対に非公開にします）

• 一番下までスクロールして、**「バケットを作成」**をクリックします。

正常に作成されれば、ひとまずOkです

ログの「自動配達員（Firehose）」を作る

次に、CloudWatchからS3へログを運んでくれる配達員を設定します。

1. 検索バーで**「Firehose」**と検索し、「Amazon Data Firehose」を開きます。

1. **「Firehose ストリームを作成」**をクリックします。

1. 送信元と送信先を以下のように設定します。
   • 送信元 (Source): Direct PUT
   • 送信先 (Destination): Amazon S3

1. Firehose ストリーム名に wp-log-delivery-stream と入力します。

宛先の設定（Destination settings）で、**「参照」**ボタンを押し、ステップ1で作ったS3バケットを選択します。私はpolepolelife-logs と名付けたのでそれを使います

一番下までスクロールして、**「Firehose ストリームを作成」**をクリックします。 (※作成完了まで数分かかることがあります)　時々エラーになるときがありますが、その場合数分待ってから、「Firehose ストリームを作成」をクリックしてください

下記のように作成されればOKです

CloudWatchに「通行証（IAMロール）」を渡す

ここが一番の「ハマりポイント」です！ CloudWatchが勝手にFirehoseへデータを送ることはできないため、「送ってもいいよ」という許可証（IAMロール）を作成します。

1. ロールの作成画面へ 検索バーで**「IAM」と検索 ＞ 左メニューの「ロール」** ＞ **「ロールを作成」**をクリック。

2. 信頼されたエンティティの選択 「カスタム信頼ポリシー」を選択し、以下のコードをそのまま丸ごと上書きコピー＆ペーストします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logs.ap-northeast-1.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logs.ap-northeast-1.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

貼り付けたら「次へ」をクリック。

3. 許可を追加 ここは何もチェックせずに、そのまま「次へ」をクリックします。（後で手動で追加します）

4. ロールの名前を決める ロール名に PolePoleCWLtoFirehoseRoleと入力し、右下の「ロールを作成」をクリックします。

5. 権限（ポリシー）を付与する 作成した PolePoleCWLtoFirehoseRoleを一覧から探してクリックします。

「許可を追加」＞「インラインポリシーを作成」をクリックし、「JSON」タブを選んで以下のコードを丸ごと上書きコピペします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "firehose:PutRecord",
                "firehose:PutRecordBatch"
            ],
            "Resource": "*"
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "firehose:PutRecord",
                "firehose:PutRecordBatch"
            ],
            "Resource": "*"
        }
    ]
}

「次へ」を押し、ポリシー名に FirehoseDeliveryPolicy と入力して「ポリシーの作成」をクリックします。 これで最強の通行証が完成しました！

CloudWatchとFirehoseを合体させる！

いよいよ最後の仕上げです。前回の記事で作ったCloudWatch Logsに、「このログをFirehoseに流してね」という指示（サブスクリプションフィルター）を出します。

1. 検索バーで**「CloudWatch」**と検索して開きます。

1. 左メニューから「ログ」＞**「ロググループ」**を開き、前回作成した lightsail-wp-access-log をクリックします。

1. **「サブスクリプションフィルター」**というタブを開きます。

1. **「作成」ボタンを押し、「Amazon Data Firehose サブスクリプションフィルターを作成」**を選択します。
2. 以下の通りに設定します。

1. Firehose ストリーム: ステップ2で作った wp-log-delivery-stream を選択

1. IAM ロール: ステップ3で作った PolePoleCWLtoFirehoseRole を選択

1. ログの形式: その他の (Other) を選択

サブスクリプションフィルターのパターン: 空白のままでOKです（すべてのログを送るため）

サブスクリプションフィルター名: send-to-firehose と入力

右下の**「ストリーミングを開始」**をクリックします！

完了！S3にログが届いているか確認しよう

お疲れ様でした！これで自動連携システムは完成です。

ログは「5分ごと」または「5MBたまるごと」にまとめてS3へ送られます。ご自身のブログに何度かアクセスしてアクセスログを発生させた後、5分〜10分ほど待ってからS3の画面を見てみましょう。

S3バケットの中に 2026/02/18/... のように年・月・日のフォルダが自動的に作成され、その中にログファイルが保存されていれば大成功です！ （※エラーログ lightsail-wp-error-log も保存したい場合は、ステップ4の手順をエラーログ側でも同じように繰り返すだけでOKです）

まとめ

これで、あなたのブログは**「サーバーに負荷をかけず」「実質0円で」「半永久的に」**アクセスログを保存できる、エンタープライズ（大企業）並みのデータ基盤を手に入れました！

次回は、このS3に溜まった大量のログを、SQLを使って一瞬で分析できる魔法のツール**「Amazon Athena」**の使い方をご紹介します。お楽しみに！

しかし、サーバーに毎回ログインして黒い画面（ターミナル）でログを確認するのは面倒ですよね。そこで今回は、Amazon Lightsailで動かしているWordPressのアクセスログとエラーログを、AWSの「CloudWatch Logs」へ自動的に転送・集約する仕組みを作ります。

月間数万PV以下の個人ブログなら、AWSの「無料枠」に収まるため維持費は実質0円！初心者の方でもコピペで進められるように、手順を1つずつ丁寧に解説していきます。

前提条件

• Amazon LightsailでWordPressを構築済みであること（標準的なBitnami版を想定）
• AWSマネジメントコンソールにログインできること
• nano もしくは vi などコマンドライン操作にアレルギーがないこと

全体像

全体像としては単純で、単にEC2のログをcloudwatch に送るだけですが、少々コマンドラインのところがめんどくさいのでこの記事では詳細に書きます。特にエージェントのインストールとか、nanoでチャカチャカ編集するところがあるので、そこのところはご了承ください。

ログ送信用の「鍵（IAMユーザー）」を作成する

Lightsailのサーバーが、AWSのCloudWatchにログを書き込むための「許可証」を作成します。

AWSマネジメントコンソールにログインし、検索バーで**「IAM」**と検索して開きます。

左のメニューから**「ユーザー」をクリックし、「ユーザーの作成」**ボタンを押します。

ユーザー名に lightsail-cloudwatch-user （お好きな名前でOK）と入力し、「次へ」をクリックします。

許可のオプションで**「ポリシーを直接アタッチする」**を選択します。

検索窓に CloudWatchAgentServerPolicy と入力し、出てきたチェックボックスにチェックを入れて「次へ」→「ユーザーの作成」を押します。

作成したユーザー（lightsail-cloudwatch-user）の名前をクリックします。

**「セキュリティ認証情報」タブを開き、少し下にある「アクセスキーを作成」**をクリックします。

ユースケースは「CLI」などを選び、作成を進めます。

最後に**「アクセスキー」と「シークレットアクセスキー」が表示されます。※これは後ですぐ使うので、必ずメモ帳などにコピーしておいてください！**（画面を閉じると二度と確認できません）

Lightsailサーバーに接続する

次に、Lightsailのサーバーに入って作業をします。

1. Lightsailの管理画面を開きます。

1. 対象のWordPressインスタンスにある**「>_」のアイコン（SSH接続）**をクリックして、ブラウザ上で黒いターミナル画面を開きます。

CloudWatch Agentをインストールする

サーバーのログをAWSへ運んでくれる「配達員（Agent）」をインストールします。以下のコマンドを1行ずつコピーして、ターミナルに貼り付け（右クリックで貼り付け）、Enterキーを押してください。

agent のプログラムをダウンロード

wget https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb

wget https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb

プログラムをインストール

sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

これでインストールは完了です！

サーバーに「鍵（認証情報）」をセットする

先程作成した「アクセスキー」をサーバーに教え込みます。

鍵を置くためのフォルダを作成

sudo mkdir -p /root/.aws

sudo mkdir -p /root/.aws

2. 鍵ファイルを作成して編集モードに入る

sudo nano /root/.aws/credentials

sudo nano /root/.aws/credentials

3. 以下の内容を貼り付けて、キーの部分を書き換える 以下のテキストをコピーして貼り付け、あなたのアクセスキー と あなたのシークレットキー の部分を、ステップ1でメモしたものに書き換えてください。

[default]
aws_access_key_id = あなたのアクセスキー
aws_secret_access_key = あなたのシークレットキー
region = ap-northeast-1

[default]
aws_access_key_id = あなたのアクセスキー
aws_secret_access_key = あなたのシークレットキー
region = ap-northeast-1

※ ap-northeast-1 は東京リージョンの意味です。

保存して閉じる 書き換えたら、キーボードの Ctrl + O を押し、そのまま Enter を押して保存。その後、 Ctrl + X で編集画面を閉じます。

ログの収集ルール（設定ファイル）を作る

「どのログファイルをCloudWatchに送るか」という指示書を作成します。LightsailのWordPress（Bitnami）は、通常 /opt/bitnami/apache2/logs/ という場所にログが貯まっています。

設定ファイルを作成して編集モードに入る

sudo nano /opt/aws/amazon-cloudwatch-agent/bin/config.json

sudo nano /opt/aws/amazon-cloudwatch-agent/bin/config.json

2. 以下の内容をそのまま丸ごとコピーして貼り付ける

JSON

{
  "agent": {
    "run_as_user": "root"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/opt/bitnami/apache2/logs/access_log",
            "log_group_name": "lightsail-wp-access-log",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/opt/bitnami/apache2/logs/error_log",
            "log_group_name": "lightsail-wp-error-log",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

{
  "agent": {
    "run_as_user": "root"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/opt/bitnami/apache2/logs/access_log",
            "log_group_name": "lightsail-wp-access-log",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/opt/bitnami/apache2/logs/error_log",
            "log_group_name": "lightsail-wp-error-log",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

※古いバージョンのBitnamiだと apache2 が apache になっていることがあります。

保存して閉じる 先ほどと同じように、 Ctrl + O → Enter → Ctrl + X で保存して閉じます。

Agentに鍵（IAMユーザー）を強制する

Lightsailの黒い画面（ターミナル）に戻って、以下の3ステップを実行してください。

共通設定ファイル（common-config.toml）を作成・編集する

以下のコマンドで、Agentの全体設定ファイルを開きます。

sudo nano /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml

sudo nano /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml

2. 以下の内容を貼り付ける

開いたファイル（おそらく空っぽです）に、以下の4行をそのままコピーして貼り付けてください。 これが「/root/.aws/credentials に置いてある鍵を使ってね」という絶対命令になります。

[credentials]
  shared_credential_profile = "default"
  shared_credential_file = "/root/.aws/credentials"

[credentials]
  shared_credential_profile = "default"
  shared_credential_file = "/root/.aws/credentials"

貼り付けたら、Ctrl + O → Enter で保存し、Ctrl + X で閉じます。

Agentを「オンプレミスモード」で再起動する

ここが一番重要です！Agentを起動する際、-m ec2 ではなく -m onPremise というオプションを指定して起動します。 これにより、Lightsailの隠しロールを無視して、先ほど指定した鍵を読んでくれるようになります。

以下のコマンドをコピーして実行してください。

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

確認してみましょう

上記のように　　

Configuration validation second phase succeeded
Configuration validation succeeded

まで出力されればOKです

AWS画面でログが届いているか確認する

最後に、AWSの画面で本当にログが見れるか確認しましょう。

1. AWSマネジメントコンソールで**「CloudWatch」**を検索して開きます。

1. 左のメニューから「ログ管理」の中にある**「ロググループ」**をクリックします。

一覧の中に lightsail-wp-access-log と lightsail-wp-error-log が作成されているはずです！

クリックして中に入ると、サーバーのアクセス履歴がリアルタイムで表示されているのが確認できます。

まとめ

お疲れ様でした！これで、サーバーに毎回ログインしなくても、AWSの画面上で安全かつ簡単にWordPressのログを確認できるようになりました。

CloudWatch Logsは月に5GBまで無料なので、個人ブログであれば料金を気にする必要はありません。

次回は、この集めたログを使って**「Kinesis Data Firehose」経由でS3へ永久保存する仕組み（しかも実質無料！）」**を構築していきます。お楽しみに！