【第二回】AWS上のWordPressに独自ドメインを設定し、Nginxで無料HTTPS化する

AWSとDockerを使ったWordPress構築の第二回目です。（※前回の記事をまだ読んでいない方は、こちらからEC2の立ち上げとWordPressの起動を済ませておいてください）

前回、EC2インスタンス上にWordPressを立ち上げることができました.。ただし、現時点ではアフィリエイトなどの商用ブログとして運営していく上での以下2点の課題があります。

URLが動的なIPアドレスになっている （例：http://13.111.22.33。インスタンスを再起動すると変わってしまう）
通信が暗号化されていない（HTTP通信） （ブラウザに「保護されていない通信」と警告が出る）

そこで今回は、ブログを商用レベルに引き上げるためのネットワーク設定を行っていきます。

具体的には、AWSの「Elastic IP」でIPアドレスを固定し、お名前.com等で取得した「独自ドメイン（例：example.com）」を設定します。さらに、Dockerに「Nginx」と「Let’s Encrypt」を追加し、通信を無料で自動HTTPS化（SSL暗号化）する構成を作ります。

今回はかなりインフラ色の濃い内容となっています。

1. Elastic IPによるIPアドレスの固定化
2. 独自ドメイン取得とDNS設定
3. Nginx-proxyを用いたHTTPS化
4. エラーと解決策
- 4.1. テーマや画像がアップロードできない（413 Request Entity Too Large）
- 4.2. URLが以前のIPアドレスに飛ばされてしまう
第二回まとめ

1. Elastic IPによるIPアドレスの固定化

まずは、取得したドメインとサーバーを結びつけるための準備として、EC2の「IPアドレスの固定」を行います。

1.1. なぜIPアドレスの固定が必要なのか

前回作成したEC2インスタンスには、インターネットからアクセスするための「パブリックIPv4アドレス（例：13.111.xx.xx）」が自動で割り当てられています。しかし、この初期設定のIPアドレスには「EC2インスタンスを再起動すると、別の数字に変わってしまう」というAWSの仕様があります。

ドメインを設定しても、紐づいているIPアドレスがコロコロ変わってしまっては、読者がブログにたどり着けなくなってしまいます。そこで、AWSが提供する 「Elastic IP」 という機能を使って、再起動しても変化しない静的なIPアドレスを確保し、EC2に割り当てる作業を行います。

1.2. Elastic IPの割り当てとEC2への関連付け

まず、AWSマネジメントコンソールにログインします。

画面上部の検索バーで 「EC2」 と検索し、EC2ダッシュボードを開きます。
左側のメニューを少し下にスクロールし、「ネットワーク＆セキュリティ」の中にある 「Elastic IP」 をクリックします。
画面右上のオレンジ色のボタン 「Elastic IP アドレスを割り当てる」 をクリックします。
設定画面が開きますが、何も変更せずにそのまま右下の 「割り当て」 をクリックします。

これで、自分専用の静的IPアドレスが発行されました。次に、これを以前作成したEC2インスタンスに紐付けます。

取得したElastic IPの左側にあるチェックボックスにチェックを入れます。
画面右上にある 「アクション」 ボタンをクリックし、「Elastic IP アドレスの関連付け」 を選択します。

関連付けの画面で、以下の2つの項目を入力（選択）します。
- インスタンス: 検索ボックスをクリックし、作成したEC2インスタンス（WordPress-Server など）を選択します。
- プライベート IP アドレス: 検索ボックスをクリックし、表示される数字（172.31.xx.xx など）を選択します。
画面右下の 「関連付ける」 をクリックします。

「Elastic IP アドレスが正常に関連付けられました」と表示されれば成功です。 EC2のインスタンス一覧画面に戻り、「パブリック IPv4 アドレス」が今取得したElastic IPの数字に変わっていることを確認しておきます。

1.3.【重要】EC2停止時のElastic IP課金について

ここで、AWSでサーバーを運用する上での「課金ルール」について記述します。

Elastic IPは、「関連付けられているEC2インスタンスが起動中であれば、無料で使い続ける」ことができます。しかし、以下のような場合は時間単位で少額のペナルティ課金（1ヶ月で約500円程度）が発生してしまいます。

Elastic IPを紐付けたまま、EC2インスタンスを停止させている時。
Elastic IPを取得したのに、どのEC2にも紐付けずに放置している時。

これは「世界で使えるIPアドレスの数は限られていて貴重なので、使わずに確保だけしている人からは料金を取る」というAWSのルールがあるためです。もし学習目的でEC2を長期間停止させておく場合は、Elastic IPの関連付けを解除し、Elastic IPを解放するようにしてください。

2. 独自ドメイン取得とDNS設定

静的IPアドレスの取得が完了したら、次は「自分だけのブログURL」となる独自ドメインを設定します。 http://13.111... のような数字の羅列ではなく、example.com のような覚えやすい名前を設定することで、ユーザーからの信頼性が上がり、Google検索等でも有利になります。

2.1. ドメイン取得サービスで独自ドメインを購入する

ドメインは世界に一つしかないため、購入orレンタルする必要があります。

AWSの中で「Route 53」というサービスを使って購入することもできますが、費用が少し割高（年間約2,000円〜）です。少しでも安く（初年度は0円〜数十円で）取得したい場合は、国内最大手のドメイン販売サイトを利用するのがおすすめです。

▼ おすすめのドメイン取得サイト

お名前.com :国内シェアNo.1。キャンペーンが多く、初年度は0円〜数十円という破格で取得できることが多いです。
シンレンタルサーバー: レンタルサーバーで有名なエックスサーバーが運営。管理画面が非常にシンプルで使いやすく、エンジニアにも人気があります。

リンク先のサイトで好きな文字列（例：my-aws-blog）を検索し、空いていれば購入手続きに進みます。ブログとして長く運営していくのであれば、定番の .com や .net を選ぶのがおすすめです。

2.2. ドメインとAWSを紐付ける「Aレコード」の設定

ドメインを購入したら、次はそのドメインの管理画面で「URLにアクセスが来たら、自身のAWS上のEC2に案内する」という設定を行います。これを「DNSのAレコード設定」と呼びます。

今回は「お名前.com」を例に解説しますが、どのサービスでも設定する中身は共通です。

ドメインを購入したサイトの管理画面にログインし、「DNS設定」 や 「ネームサーバー設定」 のメニューを開きます。
「DNSレコード設定」の追加画面で、以下のように新しいルールを登録します。

ホスト名 (Host / Name): 空白にするか、@ を入力します。

タイプ (Type / Record Type): プルダウンから A を選択します。

値 (Value / Content / 宛先): AWSコンソールで確認した、EC2の Elastic IP（例: 15.152.xx.xx） を入力します。

設定を保存すれば、ドメイン側の設定は完了です。

2.3. DNSの浸透を待つ

設定を保存した直後にブラウザで自分のドメイン（http://あなたのドメイン.com）にアクセスしても、すぐには表示されずエラーになることがほとんどです。

💡 【DNSの浸透とは？】 書き換えたDNS設定が、世界中の通信プロバイダ（ドコモやau、各種Wi-Fiルーターなど）のシステムにコピーされて行き渡るまでには、数十分から最長で24時間程度のタイムラグが発生します。これを「DNSの浸透（プロパゲーション）」と呼びます。

しばらく待ち、無事にWordPressの画面が表示されれば、インターネット上での公開は完了です。

3. Nginx-proxyを用いたHTTPS化

独自ドメインでアクセスできるようになったら、次はブログをHTTPS（SSL暗号化）に対応させます。現在のようにURLが http:// のままだと、ブラウザで「保護されていない通信」と警告が出てしまい、SEO的にもセキュリティ的にもマイナスです。

今回はDockerの強みを活かし、AWSの追加費用を一切かけずに「Nginx-proxy」と「Let’s Encrypt」という2つのコンテナを追加します。これを入れると、自動でSSL証明書を取得し、自動更新を行うWordPress環境が構築できます。

3.1. 現在のWordPressコンテナを一度停止する

設計図（docker-compose.yml）を書き換えるため、今動いているコンテナを一度片付けます。 AWS CloudShellからEC2にSSH接続し、作業フォルダで以下の停止コマンドを打ちます。（※データは永続化されているので消えません）

cd ~/my-wordpress
docker-compose down

画面に Removed と表示されれば完了です。

3.2. docker-compose.ymlをHTTPS版に書き換える

nano エディタで設計図を開き、HTTPS通信を捌くための構成に書き換えます。

nano docker-compose.yml

中身をすべて消去し（Alt + \ の後に Alt + T）、以下のコードを貼り付けます。

【重要】コピペの前に修正する箇所（3点） 以下のコード内にある your-domain.com（2箇所）をご自身が取得したドメイン名に、your-email@example.com（1箇所）をご自身のメールアドレスに書き換えてください。

version: '3'

services:
  # 1. 通信の受付・暗号化係（Nginx-proxy）
  nginx-proxy:
    image: nginxproxy/nginx-proxy
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - certs:/etc/nginx/certs:ro
      - vhost:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
      - /var/run/docker.sock:/tmp/docker.sock:ro
    restart: always

  # 2. 証明書自動取得係（Let's Encrypt Companion）
  acme-companion:
    image: nginxproxy/acme-companion
    container_name: nginx-proxy-acme
    volumes_from:
      - nginx-proxy
    volumes:
      - certs:/etc/nginx/certs:rw
      - acme:/etc/acme.sh
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      # 【修正箇所1】ご自身のメールアドレスに変更
      - DEFAULT_EMAIL=your-email@example.com
    restart: always
    depends_on:
      - nginx-proxy

  # 3. データベース（MySQL）
  db:
    image: mysql:8.0
    container_name: wordpress-db
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somesecurepassword
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpresspassword
    volumes:
      - db_data:/var/lib/mysql

  # 4. WordPress本体
  wordpress:
    image: wordpress:latest
    container_name: wordpress-app
    restart: always
    depends_on:
      - db
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpresspassword
      WORDPRESS_DB_NAME: wordpress
      # --- ここからが HTTPS(プロキシ) 用の追加設定 ---
      # 【修正箇所2】取得したドメインに変更（例: myawsblog2027.com, www.myawsblog2027.com）
      VIRTUAL_HOST: your-domain.com, www.your-domain.com
      # 【修正箇所3】取得したドメインに変更
      LETSENCRYPT_HOST: your-domain.com, www.your-domain.com
    volumes:
      - wp_data:/var/www/html

volumes:
  certs:
  vhost:
  html:
  acme:
  db_data:
  wp_data:

書き換えが終わったら、Ctrl + O → Enter → Ctrl + X で元の画面に戻ります。

3.3. EC2のセキュリティグループでHTTPSを開放する

HTTPS通信を行うには、AWS側でHTTPS（ポート443）の通信許可が必要です。

AWSコンソールのEC2から、このインスタンスの「セキュリティ」タブを開きます。
セキュリティグループのリンクをクリックし、「インバウンドルールを編集」を選択します。
「ルールを追加」を押し、タイプを HTTPS、ソースを Anywhere-IPv4 (0.0.0.0/0) に設定して保存します。

3.4. コンテナの再起動とブラウザでのHTTPSアクセス確認

以下のコマンドで、新しい4つのコンテナを立ち上げます。

docker-compose up -d

【裏側で起きていること】 起動後、裏側で「Let’s Encrypt」が、「EC2のIPアドレスと、ドメインが本当に紐づいているか」を確認しにいきます。確認が取れると、SSL証明書をダウンロードして設定してくれます。

2分ほど待ったら、ブラウザからアクセスします。先頭を https にして、https://あなたのドメイン.com にアクセスしてみてください。

ブラウザのURL欄の横に 鍵マーク（保護された通信） が表示され、WordPressの画面が出れば、HTTPS化は完了です。

4. エラーと解決策

AWSとDockerを使った構築は実際に手を動かしていると、特有のエラーに遭遇することがあります。ここでは、構築中に発生したエラーとその解決策をご紹介します。

4.1. テーマや画像がアップロードできない（413 Request Entity Too Large）

WordPressの管理画面から、Cocoonなどのテーマファイルや大きめの画像をアップロードしようとした際、画面が真っ白になって 413 Request Entity Too Large というエラーが出ることがあります。

【原因】 これはWordPressのエラーではなく、手前に立っているNginxの初期設定が原因です。Nginxはセキュリティのため、デフォルトで「外部からアップロードできるファイルの最大サイズは 1MB まで」という制限がかかっており、サイズの大きいファイルなどを弾いてしまうのです。

【解決策：アップロード上限を100MBに引き上げる】 NginxとWordPressの両方に、「もっと大きいサイズのファイルを受け取っていいよ」という設定を追加します。

CloudShellで作業フォルダに移動し、以下のコマンドで2つの設定ファイルを作成します。

# 1. Nginx用の設定ファイル（上限100MB）を作成
echo "client_max_body_size 100m;" > client_max_body_size.conf

# 2. WordPress(PHP)用の設定ファイルを作成
cat <<EOF > uploads.ini
file_uploads = On
memory_limit = 256M
upload_max_filesize = 100M
post_max_size = 100M
max_execution_time = 300
EOF

次に、作成した2つの設定ファイルをコンテナに読み込ませるため、docker-compose.yml を編集（nano docker-compose.yml）し、以下の ★の部分 を追記します。

yamlCopy# (...前略...)
  nginx-proxy:
    image: nginxproxy/nginx-proxy
# (...中略...)
    volumes:
      - certs:/etc/nginx/certs:ro
      - vhost:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
      - /var/run/docker.sock:/tmp/docker.sock:ro
      # ★ 追加: Nginxのアップロード上限を100MBにする設定
      - ./client_max_body_size.conf:/etc/nginx/conf.d/client_max_body_size.conf:ro

# (...中略...)

  wordpress:
    image: wordpress:latest
# (...中略...)
    volumes:
      - wp_data:/var/www/html
      # ★ 追加: PHPのアップロード上限を100MBにする設定
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini

設定を保存したら、docker-compose up -d --force-recreate を実行してコンテナを再起動します。これで大きなファイルも問題なくアップロードできるようになります。

4.2. URLが以前のIPアドレスに飛ばされてしまう

独自ドメインを設定したのに、ブラウザでアクセスすると自動的に古いIPアドレス（http://13.111.xx.xx など）にリダイレクトされてしまい、管理画面にログインできなくなる問題です。

【原因】 WordPressは、一番最初に初期設定を行った時のURLを、データベースの深くに「これが自分の本当の住所だ」と強く記憶する仕様になっています。そのため、後からドメインを設定しても古いIPアドレスに強制的に飛ばしてしまいます。

【解決策：データベースの記憶を強制的に上書きする】 EC2の中からデータベースに直接指示を出して、新しいドメインの情報を上書きします。 CloudShellから以下のコマンドを実行してください。

(※ wordpresspassword の部分は、ご自身が設定したパスワードに。https://your-domain.com の部分は、取得した新しいドメイン名に変更して実行してください)

docker exec -i wordpress-db mysql -u wordpress -pwordpresspassword wordpress -e "UPDATE wp_options SET option_value = 'https://your-domain.com' WHERE option_name IN ('siteurl', 'home');"

(※実行時に「Using a password on the command line…」という警告が出ますが、これはエラーではなく単なるセキュリティの注意喚起なので問題ありません。)

ブラウザは古い記憶を残していることがあるため、Chromeの「シークレットウィンドウ」などで新しいドメインにアクセスしてみてください。無事にWordPressが表示されるはずです。

第二回まとめ

これで独自ドメインとHTTPS通信を備えた、商用レベルのWebサイト構築の完了です。

インフラ側の構築はこれで完了です。 ▼ 次のステップ（第三回）では、このブログにAmazon Bedrockと連携した「AIチャットボット」を実装し、AWS WAFでセキュリティを構築します！

【第三回】Amazon Bedrockを用いたAIチャットボットを実装

AWSとDockerを使ったWordPress構築連載、最終回となる第三回目です。（※これまでの構築手順をまだ読んでいない方は、第1回・第2回からご覧ください）前回までの手順で、独自ドメインとHTTPS通信を備えた本WordPressブロ...