EC2インスタンスへのZabbix監視をAWSセキュリティグループで設計する方法｜監視サーバーの冗長化

「EC2にZabbixエージェントを入れたのに、監視がつながらない」
「セキュリティグループをどう設定すればいいか分からない」

Zabbix監視をAWSに展開するとき、一番多いつまずきがセキュリティグループの設定です。
Linuxサーバーの知識はあっても、AWSのネットワーク制御はiptablesとは別の設計が必要です。

この記事では、Amazon Linux 2023を想定環境として、EC2インスタンスへのZabbix監視をセキュリティグループで設計する手順と、監視サーバーの冗長化パターンを解説します。

AWSでZabbix監視を組む前に押さえておくこと

Zabbixによるサーバー監視では、監視サーバーが各EC2インスタンスに入った「Zabbixエージェント」と通信してメトリクスを収集します。

通常のLinuxサーバーなら、iptablesかfirewalldでポートを開ければよいのですが、AWS上のEC2はそれに加えてセキュリティグループの許可も必要です。
セキュリティグループはVPCレベルのネットワーク制御で、ここをすり抜けないとEC2のOSには通信が届きません。

Zabbixが使うポートは2種類です。
・TCP 10050：ZabbixサーバーからエージェントへのPASSIVEチェック用
・TCP 10051：ZabbixプロキシやエージェントがサーバーへデータをプッシュするACTIVEチェック用

どちらを使うかで、セキュリティグループの受信ルールの設定対象が変わります。
この記事では一般的なPASSIVEチェック構成を前提に説明します。

Zabbix監視に必要なセキュリティグループの設計手順

セキュリティグループの設計は2段階です。まず「Zabbixサーバー側のSG」を作り、次に「監視対象EC2のSG」に受信ルールを追加します。

1. 監視ポートの設計を確認する

PASSIVEチェック構成では、監視の流れは次のとおりです。

・ZabbixサーバーからエージェントへTCP 10050で接続（アウトバウンド）
・EC2エージェント側はTCP 10050でZabbixサーバーからの受信を許可（インバウンド）

セキュリティグループで設定するのは「インバウンドルール」だけで、アウトバウンドはデフォルトで全許可です。
EC2のAZや台数が増えても、セキュリティグループの組み方が正しければ個別に設定しなくて済みます。

2. Zabbixサーバー用セキュリティグループを作成する

まずZabbixサーバー自身に付与するセキュリティグループを作ります。
このSGを、後で監視対象EC2の受信ルールの「参照元」として使います。

AWSマネジメントコンソールのEC2 → セキュリティグループ → セキュリティグループを作成から、次のように設定します。

・セキュリティグループ名：sg-zabbix-server（任意）
・説明：Zabbix monitoring server
・VPC：監視対象EC2と同じVPCを選択
・インバウンドルール：Zabbix WebUI用にポート80（または443）を管理者IPに限定して追加

Zabbixサーバー自身がエージェントをポーリングするのはアウトバウンド通信です。
デフォルトのアウトバウンドルール（全トラフィック許可）で動作するので、ここでの追加は不要です。

3. 監視対象EC2のセキュリティグループに受信ルールを追加する

監視対象EC2に付与するセキュリティグループのインバウンドルールに、次の行を追加します。

・タイプ：カスタムTCP
・ポート範囲：10050
・ソース：sg-zabbix-server（上で作ったZabbixサーバーのSGのID）

ここがポイントです。ソースにIPアドレスやCIDRではなく、セキュリティグループIDを指定します。
ZabbixサーバーのEC2インスタンスを再作成してIPが変わっても、SG参照なら自動的に追従します。

IPアドレスを直書きすると、サーバー入れ替えのたびにルールを修正しなければならず、設定漏れの原因になります。

設定後、Zabbixサーバーからncコマンドでポートに到達できるか確認してください。
rc=0なら疎通できています。失敗するときは、監視対象EC2のOSでZabbixエージェントサービスが起動しているか確認してください。
セキュリティグループが正しく設定されていても、エージェントのサービスが停止していれば接続は拒否されます。
Linuxサーバー側でポートが開いているか確認する方法はLinux ポート確認の全コマンドも参考にしてください。

監視サーバーを冗長化するAWSの設計パターン

Zabbixサーバーが1台だけだと、そのEC2に障害が起きた瞬間に全監視がブラインドになります。
AWSのマルチAZ構成と組み合わせることで、監視の冗長性を確保できます。

「監視ツールを入れた＝監視できている」ではありません。監視サーバー自身が止まらない設計が必要です。
AWS上でZabbix監視を冗長化する現実的なパターンが、「Zabbixプロキシのマルチ配置」です。

EC2を使ったサーバー構築の基本的な設計については、AWS（Amazon Linux）入門でも確認できます。

1. Zabbixプロキシを使ったAZ分散の考え方

Zabbixプロキシは、Zabbixサーバーの代わりに監視データを収集・一時キャッシュする中継サーバーです。
サーバーとプロキシの接続が一時的に切れても、プロキシはローカルにデータを保持し続けます。接続が回復した時点でサーバーに転送します。

AWSで使いやすい構成は次のとおりです。

・AZ-aにZabbixサーバー：プロキシからデータを受け取り、DBに保存・WebUIを提供
・AZ-aとAZ-cにZabbixプロキシを1台ずつ：各AZの監視対象EC2を担当

各AZのEC2は同じAZのプロキシにTCP 10050で通信します。
AZ-cが障害を受けても、AZ-aのプロキシが担当するEC2の監視は継続します。

2. Zabbixプロキシ用セキュリティグループの設計

Zabbixプロキシを追加すると、セキュリティグループの設計も変わります。

・監視対象EC2のSG：ZabbixプロキシのSGからのTCP 10050受信を許可
・ZabbixプロキシのSG：ZabbixサーバーのSGからのTCP 10051受信を許可
・ZabbixサーバーのSG：プロキシのSGからのTCP 10051受信を許可

セキュリティグループを「用途ごとに分けて作る」のがAWSのベストプラクティスです。
sg-zabbix-server・sg-zabbix-proxy・sg-monitored-instances という命名で管理すると、どのSGが何の通信を許可しているか一目で分かります。

Zabbix監視設計のよくある問題と対処法

「タイムアウトでデータが取れない」場合

セキュリティグループを設定しても監視データが取得できないとき、次の順序で確認してください。

・EC2のOSでZabbixエージェントサービスが起動しているか（systemctl status zabbix-agent2）
・ZabbixサーバーのSGのアウトバウンドが全許可になっているか
・監視対象EC2のSGインバウンドルールのソースが正しいSGのIDか
・Zabbix WebUIの「ホスト」設定でIPアドレスやDNS名が正しいか

ネットワーク的に疎通できていても、ホストの設定ミスでデータが取れないケースはよくあります。

「プロキシ切り替え後にデータが空白になる」場合

Zabbixプロキシを新しいEC2に切り替えたとき、一時的にデータが途切れることがあります。
プロキシのデータベース（SQLite または MySQL）をバックアップしてから新プロキシに移行することで、データの空白期間を最小化できます。

プロキシのキャッシュ設定も確認してください。
ProxyLocalBuffer（ローカルキャッシュ保持時間）が短すぎると、サーバーとの接続断中のデータが失われます。

本記事のまとめ

AWSでのZabbix監視設計のポイントをまとめます。

やりたいこと	設定箇所・方法
ZabbixサーバーからEC2に接続する	監視対象EC2のSGインバウンドにTCP 10050を追加
IPではなくSGを参照元に指定する	ソースにZabbixサーバーのSGのIDを指定
プロキシからサーバーへデータ転送する	ZabbixサーバーのSGインバウンドにTCP 10051を追加
AZ障害時も監視を継続する	各AZにZabbixプロキシを配置してAZ分散
疎通確認する	ZabbixサーバーからncコマンドでTCP 10050を確認

Zabbix監視のセキュリティグループ設計で大事なのは「IPアドレスではなくSGのIDで参照させること」と「用途ごとにSGを分けること」の2点です。
台数が増えてもルールの修正が不要になり、冗長構成のプロキシを追加するときにも一貫した設計を維持できます。

---

• 前のページへ：CloudWatchを中心に構築するAWS運用監視の設計アーキテクチャ｜マルチアカウント対応
• この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る