【AWS】TerraformでWordPress環境を構築してみた｜SAA取得後のインフラ構築記録

1. はじめに

2007年8月生まれ、19歳です。

2026年9月にAWS Certified Solutions Architect – Associate（SAA）を取得しました。

試験には合格したものの、正直なところ「本当に自分の力だけでインフラを構築できるのか？」という不安がありました。

資格の勉強でAWSのサービスや設計について学んできましたが、それと実際に手を動かして環境を構築することは別物だと感じていたからです。

そこで今回は、SAA取得後の実践として、Terraformを使ってAWS上にWordPress環境を構築することにしました。

構築にあたってはAIにも相談しながら進めています。

構築前の経験

今回の構築に取り組む前に、以下の経験がありました。

• AWS Certified Solutions Architect – Associate（SAA）取得

• Cloud Resume ChallengeをTerraformで実装

Cloud Resume Challenge（以下、CRC）は、クラウド上に自分のオンライン履歴書サイトを構築・公開するための16ステップからなるプロジェクトです。

Cloud Resume Challenge公式サイト

CRCでは、S3やCloudFront、Lambda、DynamoDBなどを使用したサーバーレス構成をTerraformで実装しました。

しかし、簡易的なサーバーレス構成だけでは、インフラの構築から運用・監視までを経験したとは言い切れません。

そこで今回は、実際のWebサイトを稼働させながら、インフラの構築だけでなく、その後の運用まで見据えた環境づくりに挑戦することにしました。

2. インフラ構成

今回のプロジェクトでは、Terraformを使用してAWS上にWordPress環境を構築しました。

まずは、構築当初の構成を紹介します。

構築当初の構成

• Amazon EC2：t3.micro / Amazon Linux 2023

• Amazon RDS：MySQL 8.4.9 / db.t4g.micro

• Amazon EFS：WordPress関連データの保存

• Amazon VPC：AWS上のネットワーク環境

• Amazon Route 53：独自ドメイン qp001.blog のDNS管理

• Terraform：インフラ構成のコード管理

セキュリティ対策

WordPress側では、以下の対策も実施しました。

• SSH接続を自分のIPアドレスのみに制限

• 初期adminアカウントの削除

• Limit Login Attempts Reloadedの導入

• XO Securityの導入

• HTTPSへのリダイレクト設定

※セキュリティ対策については、今後も継続して見直していく予定です。

インフラ構成図

3. 構築コスト

今回、特に意識したのがAWSの利用料金です。

最初はEC2・RDS・EFSを組み合わせた構成を採用しましたが、個人のポートフォリオとして継続運用するには、コストが少し高いと感じました。

以下は、構築当初の構成における月額料金の試算です。

構築当初の月額コスト

※us-east-1での試算です。
※1ドル155円換算、2026年10月時点の価格を参考にしています。
※実際の請求額はデータ転送量やリクエスト数などによって変動します。

コストを見直した結果

月額約4,600円という金額は、個人で運用するポートフォリオとしては少し負担が大きいと感じました。

そこで、構成を見直すことにしました。

最終的にはRDSとEFSを削除し、WordPressとMariaDBをEC2内に同居させる構成へ変更しました。

変更後の構成と月額コストは以下の通りです。

当初の約4,600円/月と比較すると、月額コストを大幅に削減できました。

個人で継続的に運用することを考えると、今回の構成変更は大きな改善になりました。

4. 構築中に苦戦したこと

今回の構築では、想像以上にエラーやトラブルに遭遇しました。

特に印象に残っているものを3つ紹介します。

Terraformの変数ファイルに関する問題

最初に苦戦したのが、Terraformの変数ファイルに関する問題です。

今回は、データベースのユーザー名やパスワード、EC2のキーペア名などを terraform.tfvars で管理する構成にしていました。

しかし、変数ファイルの内容や指定方法に不整合があり、想定していた値で構築できない問題が発生しました。

原因を調べるために variables.tf や terraform.tfvars の内容を見直し、変数の定義と実際に渡している値を確認しました。

最終的には、変数の不整合を修正することで解決しました。

今回の件で、Terraformでは変数の定義だけでなく、どのファイルから値が読み込まれているのかを理解することも重要だと学びました。

amazon-efs-utilsのインストール失敗

次に苦戦したのが、EFSをマウントするために必要な amazon-efs-utils のインストールです。

最初は以下のコマンドを使用していました。

sudo yum install -y amazon-efs-utils

しかし、パッケージのインストールに失敗しました。

コードを見直したところ、Amazon Linux 2023ではパッケージ管理にDNFが採用されていることを踏まえ、以下のように変更しました。

sudo dnf install -y amazon-efs-utils

これによってインストールできるようになりました。

普段はAWSのサービスやTerraformに意識が向きがちでしたが、OSの仕様やパッケージ管理についても理解しておく必要があると感じました。

RDSの延長サポートが有効になっていた

今回、最も焦ったのがRDSの延長サポートに関する問題です。

当初は、Terraformで以下のようにRDSを定義していました。

resource "aws_db_instance" "wordpress" {
  engine         = "mysql"
  engine_version = "8.0.46"
}

このとき、RDSの延長サポートに関する設定を明示的に指定していませんでした。

構築後、しばらくしてからAWSのクレジット残高が急激に減少していることに気が付きました。

原因を調べたところ、MySQL 8.0系の延長サポートが関係していることが分かりました。

そこで、まずAWS CLIを使って延長サポートを無効化し、MySQLのバージョンも8.4.9へ変更しました。

その際、念のため変更前のデータベースのバックアップも取得しました。

Terraform側も以下のように修正しました。

resource "aws_db_instance" "wordpress" {
  engine                  = "mysql"
  engine_version          = "8.4.9"
  engine_lifecycle_support = "open-source-rds-extended-support-disabled"
}

しかし、これだけでは問題は解決しませんでした。

terraform plan を実行したところ、RDSやEC2がReplacement（再作成）の対象として表示されたためです。

既存のリソースを不用意に再作成しないよう、差分の原因を確認しながら lifecycle の ignore_changes なども見直しました。

最終的に設定を調整し、再度 terraform plan を実行したところ、No changes と表示されました。

この表示を見たときは、本当にホッとしました。

今回の経験を通じて、Terraformは単にコードを書いてリソースを作成するだけではなく、既存環境との状態の差分を理解し、意図しない変更を防ぐことも重要だと学びました。

5. 今後の取り組み

今回の構築は、あくまでスタート地点だと考えています。

今後は、構築した環境を実際に運用しながら、以下のことに取り組んでいきたいです。

CloudWatchによる監視・アラーム設定

まずはCloudWatchを使用した監視環境を整備したいと考えています。

CPU使用率やメモリ使用率、ディスク容量などを監視し、異常が発生した際に検知できる環境を目指します。

※SOAの学習で得た知識も活用して実装したいです。

障害注入テスト

次に挑戦したいのが、障害注入テストです。

意図的に障害を発生させ、その際にどのような影響が出るのか、どのように検知・復旧できるのかを確認したいと考えています。

まだ十分な知識が身についているとは言えないため、こちらは基礎を固めてから取り組む予定です。

運用記録と継続的な改善

構築して終わりではなく、実際に運用した記録も残していきたいです。

例えば、以下のような内容です。

• AWSリソースの監視結果

• 発生したエラーや障害

• 原因調査と復旧までの過程

• Terraformによる構成変更

• コスト削減やセキュリティ面の改善

こうした経験を積み重ねて、単にAWSを触ったことがあるだけではなく、インフラを理解して運用・改善できる力を身につけたいです。

6. 構築してみた感想

SAAを取得したとき、これでインフラを構築できるとは正直思っていませんでした。

実際に手を動かしてみると、エラーの連続でした。

特にRDSへの接続がうまくいかなかったときは、かなり焦りました。

それでも、一つずつ原因を調べて修正し、最終的にWordPressの画面が表示された瞬間は素直に嬉しかったです。

もちろん、今回の経験だけでクラウドエンジニアとして必要なスキルが身についたとは思っていません。

また、AIにも相談しながら構築しているため、すべてを自分一人で実装できたわけでもありません。

ただ、AIが提示したコードをそのまま使うのではなく、エラーの原因を調べ、構成を見直しながら進めたことで、少しずつ理解を深めることができました。

SAAで学んだ知識を、実際に動くインフラへと変えられたことは、自分にとって大きな経験になりました。

次の目標は、SOAで学んだ知識を活用して監視環境を整備し、構築したインフラを継続的に運用・改善していくことです。

まだまだ勉強することは多いですが、これからも学習過程や実際に取り組んだことを、このブログに記録していきたいと思います。

最後まで読んでいただき、ありがとうございました。