本記事は「【AWS EC2 構築 初心者向け】WordPress本番運用で設定した監視設定」について解説させて頂きます。
AWSでEC2インスタンスを立ち上げて、WordPressのブログやWebサイトを作ってみたものの、「構築した後は、一体何をすればいいんだろう？」
「とりあえず動いてはいるけれど、セキュリティや障害対策はこれで大丈夫なのかな……」
せっかく苦労してAWS EC2を構築したのに、そのまま放置してしまうのは非常に危険です。
本番環境としてWordPressを安定して運用するためには、構築後の「運用監視」や「セキュリティ対策」が命になります。
この記事では、実際にAWS EC2でWordPressを本番運用している筆者が、構築後に設定したインフラ構築・運用監視・運用保守の3つのカテゴリ、計22項目に分けてご紹介します。
今回解説していくのは運用監視のカテゴリになります。
「EC2を立てた後にここまでやると本番運用レベルになる」という全体像が掴める内容になっています。
手順書のような細かい設定方法ではなく、「なぜそれを設定するのか（目的）」を中心に解説させて頂きますので、参考程度に読んで頂けますと幸いです！
- GuardDuty：AWS環境全体のインテリジェントな脅威検知
- Cloud Trail：「誰が何をしたか」を記録する監査ログ
- CloudWatch Agent：メモリやディスクの「中身」を覗くセンサー
- CloudWatchアラーム ：異常事態をいち早く知らせるアラート
- CloudWatch ダッシュボード：サーバーの健康状態を一 画面で可視化
- CloudWatch Logs：散らばるログを1箇所に集約・保管
- Logs Insights：大量のログから必要な情報を一瞬でクエリ分析
- SNS：異常通知をメール
- EventBridge：コンソールへのサインインをリアルタイム監視
- EventBridge (Health)：AWS側の障害やメンテナンス情報をキャッチ
自由度が高いですよね！
教えてください！
AWS EC2 構築 初心者向け｜サーバーは立ち上げて終わりではない
EC2が立ち上がり、無事にWordPressの画面が表示されたときは感動したのを覚えています。
しかし、Webサイトは「作って終わり」ではありません。
むしろ、立ち上げた瞬間からが本当のスタートです。
インターネット上に公開されたサーバーは、常に以下のようなリスクに晒されています。
- アクセス急増によるサーバーダウン（メモリ不足など）
- 悪意のある第三者からのサイバー攻撃や不正ログイン試行
- ハードウェアの故障や、突然のディスク容量パンク
これらが発生した際、監視をしていないと「ユーザーから『サイトが見られない』と連絡があって初めて気づく」という最悪の事態になりかねません。
セキュリティは必須です！
AWS EC2 構築 初心者向け｜設定すべき項目
本番運用レベルのシステムにするためには、サーバーの健康状態を常に可視化し、異常があればすぐに検知できる「運用監視」の仕組みが不可欠なのです。
まずは全体として設定すべ項目を、以下の表で確認してみましょう。
| GuardDuty | AWS環境全体のインテリジェントな脅威検知 |
| Cloud Trail | 「誰が何をしたか」を記録する監査ログ |
| CloudWatch Agent | メモリやディスクの「中身」を覗くセンサー |
| CloudWatchアラー ム | 異常事態をいち早く知らせるアラート |
| CloudWatch ダッシュボード | サーバーの健康状態を一 画面で可視化 |
| CloudWatch Logs | 散らばるログを1箇所に集約・保管 |
| Logs Insights | 大量のログから必要な情報を一瞬でクエリ分析 |
| SNS | 異常通知をメール |
| EventBridge | コンソールへのサインインをリアルタイム監視 |
| EventBridge (Health) | AWS側の障害やメンテナンス情報をキャッチ |
それでは、各カテゴリの詳細を「設定する目的」と合わせて見ていきましょう！
いろんな設定がありますね！
AWS EC2 構築 初心者向け｜運用監視編の設定
EC2でWordPressを本番運用する上で、筆者が「絶対に外せない」と確信している運用監視の設定を詳しく解説します。
GuardDuty
AWS環境全体を24時間体制で見張り、不正利用やマルウェア感染などの脅威をいち早く検知する。
AWSのインテリジェントな脅威検知サービスです。
有効化するだけで、機械学習を用いて不審なアクティビティ（見慣れないIPからのアクセスや、EC2の異常な挙動など）を自動で検出してくれます。
設定が非常にシンプルでありながら、セキュリティの安心感を格段に引き上げてくれる頼もしい存在です。
CloudTrail
AWSアカウント内で「誰が・いつ・何に対して・どのような操作を行ったか」の履歴をすべて記録し、監査やトラブルシューティングに役立てる。
AWSのAPI操作ログを自動で記録するサービスです。
このログを長期間安全に保存するために、耐久性の高いS3バケットにエクスポートする設定を行いました。
万が一、設定が勝手に書き換わっていたり、不正な操作が行われたりした際に、原因究明のための決定的な証拠（ログ）を確保できます。
CloudWatch Agent
標準のCloudWatchでは取得できない、EC2の「メモリ使用率」や「ディスク容量」といったサーバー内部の詳細なデータを監視する。
EC2インスタンスの内部に専用のエージェントソフト（CloudWatch Agent）をインストールしました。
これにより、WordPressの動作に直結するメモリ使用率や、画像アップロードなどで消費されるディスク使用率を、詳細に「60秒間隔」で収集・送信できるようになります。
CloudWatchアラーム
サーバーの負荷が限界に達したり、ストレージがパンクしそうになったりした際に、手遅れになる前に管理者に通知する。
収集したメトリクスに対してしきい値を設定し、それを超えたら自動でアラートを上げる仕組みです。
筆者の環境では、以下の条件でアラームを設定し、異常検知時に即座にメール通知が飛ぶようにしています。
- メモリ使用率：80%超過時
- ディスク使用率：85%超過時
- CPU使用率：80%超過時
CloudWatchダッシュボード
複数の監視データを1つの画面にまとめ、サーバーの稼働状況をひと目で直感的に把握できるようにする。
CPU使用率、メモリ使用率、ディスク容量、ネットワークトラフィックなどの主要なグラフを一画面に並べた専用のダッシュボードを作成しました。
トラブル発生時に「今、何が起きているのか」を複数の視点から同時に確認できるため、状況判断のスピードが圧倒的に上がります。
CloudWatch Logs
EC2内に散らばるWordPress（Apache）のアクセスログやエラーログをAWS上に集約し、サーバーが万が一壊れてもログを失わないようにする。
EC2内のログファイルをCloudWatch Logsにリアルタイムで転送する設定を行いました。
サーバー内にログを溜め込みすぎるとディスクを圧迫するため、CloudWatch側での保持期間を「7日間」に制限し、古いログは自動で削除されるようにしてコストと容量を最適化しています。
CloudWatch Logs Insights
大量のアクセスログの中から、特定の不具合や攻撃の予兆を、簡単なクエリを使って一瞬で分析・抽出する。
CloudWatch Logsに溜まったログに対して、SQLライクなクエリを実行できる検索・分析ツールです。
例えば、「ステータスコード5xx（サーバーエラー）の発生回数を時間帯別で集計する」クエリや、「アクセスページTOP10を抽出する」クエリをあらかじめ保存しておき、サイトの挙動が重くなった原因を秒速で特定できるようにしています。
Amazon SNS (Simple Notification Service)
CloudWatchアラームや各種イベントからの通知を、管理者のメールアドレスへと確実に届けるための「ハブ」を作る。
AWS内の通知配信サービスです。CloudWatchアラームや後述のEventBridgeが発生させた「異常事態」のイベントをSNSトピックが受け取り、登録しておいた自分のメールアドレスへとプッシュ通知（メール送信）する仕組みを構築しました。
すべての通知の「司令塔」として機能します。
Amazon EventBridge（ログイン通知）
身に覚えのないAWS管理コンソールへのログイン（不正アクセス）を、リアルタイムで検知して身を守る。
AWSアカウントに対するサインイン（ログイン）イベントをトリガーにして、SNS経由でメールを送信するルールを作成しました。
自分がログインした時にも通知が来ますが、「今、誰かがAWSに入った」という事実をリアルタイムで把握できるため、アカウント乗っ取りなどの最悪のシナリオを初期段階で防ぐことができます。
Amazon EventBridge（AWS Health通知）
AWS側のインフラ障害や、EC2が稼働している物理サーバーのメンテナンス情報をいち早くキャッチし、事前の対策を取れるようにする。
AWSの公式な稼働状況やメンテナンス情報を通知する「AWS Health」のイベントを監視するルールを設定しました。
例えば、「あなたのEC2が動いている物理ホストが、○月○日にメンテナンスのため再起動されます」といった重要なお知らせをメールで自動受信できるため、事前にWebサイトのメンテナンス予告を出すなどの計画的な対応が可能になります。
AWS EC2 構築 初心者向け｜監視環境を実際に構築した感想
監視環境を構築し、定期的にダッシュボードを見ていますが、変化や問題は起きてないな〜ぐらいの感想です。
メモリやCPUの閾値設定が超えることはないので、その後の対応の仕方をどう学ぼうか模索している最中です。
テスト環境を作るのも良いかな？と思いましたが、AWS環境の更なる構築や当サイトを伸ばすこと、Linux学習をする必要があるので一旦本番環境のみで学習していく予定です、
これらの設定をするにあたり、いろいろ調べながら作業をしたため物凄く時間が掛かりました。
費用が掛かってしまう設定もありましたが、AWS学習をするにあたり必要な投資ですし本格運用も学びたかったので結果として満足しています。
実際に構築することに意味があります！
【まとめ】【AWS EC2 構築 初心者向け】WordPress本番運用で設定した監視設定
ここまでいかがでしたでしょうか？
本記事は「【AWS EC2 構築 初心者向け】WordPress本番運用で設定した監視設定」について解説させて頂きます。
今回解説させて頂いた内容は一度にすべてやる必要はありません。
まずは「Webサイトの公開」、次に「データの保護（バックアップと監視）」、最後に「自動化と高度なセキュリティ」というように、ステップを踏んで進めていくのがおすすめです。
EC2は自由度が高く非常に強力なサービスですが、その分「自分で守る」という意識が大切になります。
この記事で紹介した設定を取り入れて、ぜひ学習するだけでなく「安心・安全な本番運用」を実現してみましょう！
お互い頑張りましょう！
頑張ります！
コメント