はじめに

本記事は「AWS EC2 × Zabbix監視基盤構築シリーズ」の第1回です。

全4回の記事を通して、
AWS EC2上にZabbixを構築し、
EC2インスタンスを監視対象とする検証を行います。

また、監視ログやメトリクスについては、
将来的な分析および長期保管を想定し、
S3への格納を前提とした構成にします。

第1回では

EC2インスタンスの作成、
セキュリティグループ設定、
SSH接続確認

を扱います。

構成図

本検証の全体構成を以下に示します。

本構成では、単一のEC2インスタンス上に
Zabbix Server および Zabbix Agent を構築し、
同一インスタンスを監視対象として登録します。

取得した監視データおよびログは、
CloudWatch Logs を経由して S3 に集約し、
長期保管および分析に利用する想定です。

本記事では、以下の範囲を対象とします。

・EC2インスタンス作成
・セキュリティグループ設定
・SSH接続確認

Zabbixの構築および監視設定については、次回の記事で記載します。

※ 本記事では詳細な設定は扱いませんが、
後続のZabbix構築に備え、セキュリティグループでは
Zabbix Agent（10050）および Zabbix Server（10051）のポートを
事前に許可しています。

IAMユーザーとグループ設計

本検証ではAWSのベストプラクティスに基づき、
rootユーザーは使用せず、IAMユーザーを用いて作業を行う構成とします。

また、IAMユーザーに対して直接ポリシーを付与するのではなく、
グループにポリシーをアタッチする方式を採用します。

リージョンの確認

AWSアカウントを作成して、ログインします。
まずは利用するAWSリージョンを確認します。

AWSでは、サービスやリソースはリージョン単位で管理されるため、
意図しないリージョンでリソースを作成した場合、
コスト管理や運用管理が複雑化します。

ap-northeast-1（東京リージョン）を利用します。

IAMユーザーとグループの作成

IAMコンソールより、
「IAM → ユーザー → ユーザーの作成」を選択します。

ユーザー名には zabbix-server を指定します。
※ ユーザー名は任意です。

「AWS マネジメントコンソールへのユーザーアクセスを提供する（オプション）」
にチェックを入れ、次へ進みます。

IAMユーザーに対して直接ポリシーを付与するのではなく、
グループにポリシーをアタッチし、
ユーザーをグループに所属させることで権限管理を行う構成とします。

そのため、「ユーザーをグループに追加」を選択します。

ユーザーを所属させるグループが存在していないため、
「グループを作成」から新規グループを作成します。

グループ名には zabbix-group を指定します。
※ グループ名は任意です。

グループ名および、グループにアタッチする権限を選択します。

本検証では、権限付与の挙動を確認するため、
グループにはあえて許可ポリシーを付与せずに進めます。

ここで表示される情報は作成したIAMユーザーのログイン時に必要になります。
忘れないように注意します。

権限不足エラーを確認

先ほどのURLをブラウザに入力して、ユーザー名とパスワードを入力してログインします。
パスワードの変更を求められるので変更します。

EC2を見てみると、エラーが出ています。

エラーメッセージを確認すると、IAMポリシー不足により拒否されています。

ポリシー不足による挙動が確認できたので、
必要なポリシーをこのアカウントが所属するグループにアタッチしていきます。

IAMポリシーのアタッチ

まずは AmazonEC2ReadOnlyAccess をグループにアタッチして、挙動を確認します。

AmazonEC2ReadOnlyAccessの権限が与えられたことで、エラーが一気に減りました。

必要になるポリシーをまとめてアタッチします。
AmazonEC2FullAccessをつけるため、AmazonEC2ReadOnlyAccessは削除しました。
※AmazonEC2FullAccessには、AmazonEC2ReadOnlyAccessが包含されているため。

アタッチしたポリシーの説明

AmazonEC2FullAccess
EC2作成・起動・停止・削除
セキュリティグループ編集
キーペア作成
※「検証のため FullAccess。本番では最小権限」
　
AmazonS3FullAccess
バケット作成
Zabbixログや検証ファイル保存
EC2 → S3 アップロード
　
CloudWatchReadOnlyAccess
EC2のCPU使用率確認
Zabbixとの役割分担理解
　
IAMReadOnlyAccess
自分のIAM権限確認
ロールやポリシー構成の把握

EC2インスタンス作成

作成したIAMユーザーでログインします。
EC2インスタンスを起動します。

EC2 → インスタンス → インスタンスの起動

以下はEC2の設定例です。
AMIはUbuntu Server 22.04 LTSを選択しました。

名前　zabbix-server
AMI　Ubuntu Server 22.04 LTS
インスタンスタイプ　t3.micro
キーペアを作成
名前：zabbix-key
形式：pem
※キーペアは再発行できないため厳重に管理

セキュリティグループの設定

インスタンスの起動と同時にセキュリティグループの作成をします。
インバウンドルールは以下のように設定しました。

セキュリティグループ名: ZabbixServerTest

アウトバウンドルールはデフォルトにしました。
準備はできたので、インスタンスを起動します。

AMI に Ubuntu Server 22.04 を採用した理由

本検証では、EC2 の AMI として Ubuntu Server 22.04 LTS を採用します。

当初は Amazon Linux 2023 を利用して検証を進めていましたが、
後続工程である Zabbix のインストールにおいて、
公式リポジトリおよび依存パッケージの互換性に関する問題が発生し、
必要なパッケージを正常に導入できませんでした。

Zabbix 6.0 LTS は、RHEL 系および Ubuntu LTS 環境での利用実績が多く、
特に Ubuntu 22.04 は公式ドキュメントや検証事例が豊富に公開されています。

そのため、本検証では安定した検証環境の確保を優先し、
AMI を Ubuntu Server 22.04 LTS に変更して検証を実施します。

SSH接続確認

ローカルPCから、先ほど作成したキーペアを使用して、
EC2インスタンスにSSHで接続します。

ssh -i <キーのパス> ubuntu@<EC2のパブリックIP>

以下の表示が出たので、ログインできました。

Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-1040-aws x86_64)

まとめ

本記事では、AWS EC2 上に Zabbix を構築する検証の第一段階として、
IAM ユーザーを用いた権限設計、
EC2 インスタンスの作成、
セキュリティグループ設定、
および SSH 接続確認までを実施しました。

検証にあたっては、root ユーザーを使用せず、
IAM ユーザーおよびグループによる権限管理を行う構成としました。

また、権限不足によるエラーを意図的に確認することで、
各操作に必要となる IAM ポリシーの整理を行いました。

EC2 の AMI については、後続の Zabbix 構築工程で発生した互換性問題を踏まえ、
情報量および安定性を考慮し、Ubuntu Server 22.04 LTS を採用しています。

次回の記事では、
EC2 上に Zabbix Server / Agent を構築し、
EC2 インスタンスを監視対象として登録する手順、
および監視データ取得について記載します。