はじめに

久々に AWS を触って、WordPress をデプロイしました。

AWS は多種多様な IT リソースを必要な時に必要なだけ使える世界的なクラウドサービスであり、多くの企業で採用されています。

サービスを運用する上での選択肢としても AWS が挙げられます。

だからこそ学ぶ価値があると考えています。

過去に AWS を使ったことがあるのですが、当時はうまく使いこなせず、「予期せぬ高額請求が来たらどうしよう…」と金銭的な怖さからアカウントを解約してしまった苦い経験があります。

本記事では、AWSアレルギーだった私が、AWS 上に WordPress を構築し、独自ドメインによる HTTPS（SSL）化、さらにエラー・死活監視の導入までをやり切ったプロセスと学びをまとめました。

対象読者

AWS をこれから触り始める初学者の方
VPC、EC2、RDS、Route 53、ALB を組み合わせた一連のインフラ構築の流れを掴みたい方
過去に AWS で挫折した、または請求が怖くて一歩踏み出せない方

AWS 上に WordPress を構築、一連のサービスについて、公式のチュートリアルが充実しており、初学者には最適だと思われます。

技術スタック・構成

インフラ: AWS (VPC, EC2, RDS, Route 53, ACM, ALB)
OS/ミドルウェア: Amazon Linux 2023, Apache (httpd)
言語: PHP
DB: Amazon RDS for MySQL
DBクライアント: MariaDB
CMS: WordPress
運用監視: Sentry, UptimeRobot

実装プロセス

1. VPC（仮想ネットワークの構築）

まずは AWS 上に仮想ネットワーク（VPC）を作成します。

作成した VPC の中に、2つのパブリックサブネットと、2つのプライベートサブネットを用意しました。

パブリックサブネット: インターネットから誰でもアクセスできる領域。Webサーバー（EC2）などを配置します。

プライベートサブネット: インターネットからの直接アクセスを遮断する領域。データベース（RDS）など、不特定多数に見られたくない重要なリソースを配置します。

さらに、外部と通信するためのインターネットゲートウェイや、通信の経路を決めるルートテーブルを作成して VPC にアタッチします。

最初のVPCからネットワーク周りの設定に加えて理解が難しかったです。

そこで AWS公式のチュートリアルを参考にしたところ、VPCの作成画面で「VPC 設定」を「VPC など」を選択すると、必要なサブネット・インターネットゲートウェイ・ルートテーブルを全自動で一括作成してくれました。

仕組みに慣れるまでは「VPC など」から作成するのが非常におすすめです。

2. EC2（仮想サーバーの起動）

Webサーバーとなる EC2 インスタンスを立ち上げます。

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

EC2用のセキュリティグループを作成し、インバウンドルール（入ってくる通信の規則）を以下のように設定します。

HTTP (ポート80): 全て許可（0.0.0.0/0）
SSH (ポート22): 自分のIPアドレスからのみ許可（マイIP）※セキュリティ確保のため

インスタンスの起動とSSH接続

公式チュートリアルを参考にインスタンスを起動します。

この際、キーペア（.pemファイル）の発行とパブリック IP の自動割り当てを有効にすることを忘れないよう注意が必要です。

起動後、ローカルのターミナルからキーペアがあるディレクトリに移動し、以下のコマンドで EC2 に SSH 接続します。

# キーペアのアクセス権限を所有者のみに制限（必須）
chmod 400 プライベートキー.pem

# SSHでEC2インスタンスに接続(SSH クライアント->例:からコピペ)
ssh -i "プライベートキー.pem" ec2-user@<EC2のパブリックDNSまたはIPアドレス>

これにより EC2 インスタンス内で Linux コマンドを実行できる環境が整いました。

3. RDS（データベースの構築）

WordPress のデータを保存するリレーショナルデータベース（RDS）を構築します。

DB用のセキュリティグループを作成

インバウンドルール: MySQL/Aurora (ポート3306) を選択し、EC2のセキュリティグループからの通信のみを許可するように制限します。

RDS インスタンスの作成（フル設定）

エンジンのタイプ: MySQL
デプロイオプション: 単一の DB インスタンス
マスターユーザー名とパスワードを設定（メモを忘れずに）
ネットワーク設定: 先ほど作成した VPC、DB サブネットグループ、DB 用セキュリティグループを選択
パブリックアクセス: なしに設定（プライベートサブネットに配置するため）

4. WordPress のインストールと初期設定

EC2 インスタンスに再接続し、公式手順に従ってミドルウェアのインストールと WordPress の配置を行います。

各コマンドで権限エラーが出る場合は、先頭に sudo をつけて実行します。

以下は頻繁に使用した操作コマンドです。

# データベースおよびウェブサーバー（Apache）を起動
sudo systemctl start httpd

# wp-config.php の編集（DB名やパスワードを設定）
sudo nano wordpress/wp-config.php

# WordPress ファイルを Apache のドキュメントルート以下にコピー
sudo cp -r wordpress/* /var/www/html/

# ステータス確認コマンド
sudo systemctl status httpd

インストールが完了したら、EC2 インスタンスのパブリック IP アドレスをブラウザで開くことで、WordPress へアクセスします。

詳細にある、「パブリック IPv4 アドレス」をURLへ貼り付けます。

この時、httpsでなく、httpである必要があります。

インストール完了後、EC2 の「パブリック IPv4 アドレス」をコピーしてブラウザのURL欄に貼り付けます。

無事に WordPress の初期設定画面が表示されれば成功です！

http:// でアクセス
※この時点ではまだ SSL 化していないため、https:// ではなく http:// でアクセスする必要があります。

5. Route 53（独自ドメインの取得と紐付け）

URL を数字の IP アドレスではなく、オリジナルのドメインでアクセスできるようにします。

公式ガイドを参考に、Route 53 から直接ドメインを購入しました。

AWS 内で購入するとその後の設定が非常にスムーズです。
今回は練習用の使い捨てドメインだったため、最安値圏の .click ドメイン（約3ドル / 450円程度）を取得しました。

1年で自動更新をオフにしておけば、低コストで安全に練習ができます。

Aレコードの登録

取得したドメインのホストゾーンを開き、以下の内容でレコードを作成します。

レコード名: 空白（または www など）
レコードタイプ: A - IPv4 アドレスにトラフィックをルーティングします
値: 作成した EC2 インスタンスの「パブリック IPv4 アドレス」
ルーティングポリシー: シンプルルーティング

設定後、取得した独自ドメイン（ http://自分のドメイン）でブラウザからアクセスし、WordPress 画面が表示されることを確認します。

6. ACM × ALB で HTTPS化（SSL暗号化）

最後に、セキュリティを高めるために通信を HTTPS 化（常時SSL化）します。

AWS Certificate Manager (ACM) での証明書発行

パブリック証明書をリクエストします。

ACM コンソールからパブリック証明書をリクエストします。

ドメインの所有権確認として「DNS 検証」を選択し、Route 53 に検証用レコードを登録します。

メールなども確認してしばらくすると証明書のステータスが Issued (発行済み) になりました。

Application Load Balancer (ALB) の構築

HTTPS 通信を受け止めるために、ロードバランサーを導入します。

ターゲットグループの作成

対象として作成済みの EC2 インスタンスを登録します。

ALB の作成

ロードバランサーのタイプ：Application Load Balancer
VPC と2つのパブリックサブネット、ターゲットグループは作成したものを選択
スキーム: インターネット向け
ネットワークマッピング: 該当の VPC と、2つのパブリックサブネットを選択
セキュリティグループ: EC2 用のセキュリティグループを選択
リスナーとルーティング
- HTTP (80ポート): ターゲットグループへ転送
- HTTPS (443ポート) を追加: ターゲットグループへ転送。同時に、ACM で作成したパブリック証明書を選択

セキュリティグループのアップデート

EC2/ALB に適用しているセキュリティグループのインバウンドルールに、外部からの HTTPS (ポート443 / 0.0.0.0/0) を許可するルールを追加します。

完了したら、ロードバランサーの DNS 名に HTTPS 通信して、WordPress のページが表示されることを確認します。

Route 53 の宛先変更

独自ドメインのアクセス先を「EC2 の IP アドレス」から「ALB の DNS 名」へと変更します。
Route 53 の A レコードを編集し、「エイリアス」をオンにして先ほど作成した ALB を選択します。

HTTP から HTTPS へのリダイレクト設定

http://... でアクセスしてきたユーザーを自動的に https://... へ転送する設定を ALB 側で行います。

ALB の HTTP (80ポート) リスナーのルールを編集
デフォルトアクションを「転送」から「URL にリダイレクト」に変更
プロトコルを HTTPS、ポートを 443 に指定し、ホスト・パス・クエリは元のまま（ #{host}, #{path}, #{query} ）

完了したら、独自ドメインに HTTPS 通信して、WordPress のページが表示されることを確認します。

CSSやJavaScriptが崩れる問題

HTTPS でアクセスできるようになりましたが、レイアウト（CSS/JS）が完全に崩れていました。これは WordPress 内部で「自分はまだ HTTP で動いている」と誤認しているために発生する「Mix Content（混在コンテンツ）」エラーです。

これを解決するため、EC2 内の wp-config.php に以下の設定を追記しました。

$_SERVER['HTTPS']='on';
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

これで無事に、独自ドメインかつ綺麗に SSL 化された WordPress サイトが公開できました。

運用・監視ツールの導入

構築して終わりではなく、実運用を想定して以下の2つの外部ツールを導入しました。

エラー監視：Sentry

アプリケーション内部のエラーをリアルタイムで検知・通知してくれるツールです。

プラットフォームとして PHP および JavaScript を選択してプロジェクトを作成。

WordPress プラグインである「Sentry for WordPress」をインストールし、Sentry コンソールから取得した Client Keys (DSN) を設定するだけで簡単に連携できました。

Sentry コンソールの Client Keys (DSN)は、左メニュー > Settings > Projects > 自分のプロジェクト > Client Keys (DSN)にあります。

これでコードエラーが発生しても即座に気づくことができます。

死活監視：UptimeRobot

UptimeRobot を使い、サイトがダウンしていないかを外部から定期監視する設定を行いました。

こちらは登録して URL を入力するだけで、24時間サイトが生きているかをチェックしてくれるので、非常に手軽で強力です。

苦戦したポイントと解決策

料金請求への恐怖との戦い

過去の経験から「お金がかかる恐怖」が常にあり、学習を中断するたびに EC2 や RDS の停止操作を行っていました(もしまたお金がかかりそうなら解約します…笑)。

初期段階では Route 53 を EC2 のパブリックIPへ直接向けていたため、
EC2 の停止・起動時に IP アドレスが変わり、
サイトへアクセスできなくなる問題が発生しました。

後に ALB を導入し、Route 53 を ALB 向けの Alias レコードへ変更することで、この問題を解消しました。

数字だらけコンソールとの戦い

また、数字だらけのコンソール画面や IP アドレスの変動、進数の概念などに最初は強烈なアレルギーが出そうでしたが、粘り強く触り続けたことで、徐々にAWSの画面操作やインフラのネットワーク構造に対する解像度が上がっていくのを実感しました。

まだまだIPアドレスに対する理解が必要だと感じます。

FTP接続権限のエラー対処

WordPress管理画面からプラグインなどをインストールしようとした際、FTPの接続情報を求められる権限エラーが発生しました。

wp-config.phpとfunctions.phpの設定変更と以下のコマンドで所有者を Apache ユーザーに変更することで解決しました。

sudo chown -R apache:apache /var/www/html

おわりに

過去に一度でも AWS アカウントを作成したことがある場合、同じクレジットカードや個人情報を使うと「無料利用枠」が対象外になってしまうのは、少し辛いポイントでした（完全に自業自得なのですが…笑）。

しかし、数年前はあれほど「AWS は怖い」と逃げてしまっていた状態から、自分の手で一つずつ設定を紐解き、最終的に「意外と便利で面白いツールじゃないか！」と感じられるまでになれたことは、大きな収穫です。

今回は手動での構築でしたが、今後はエラー監視だけでなく、自動化（IaC）や CI/CD、コンテナ化などにも挑戦し、さらにインフラ知識の解像度を上げていきたいと思います！