AWSとは?初心者でもできるWordPress導入手順


「AWSでWordPressを動かしたい」と検索すると、EC2にApacheとMySQLを入れる長大な手順か、逆に「レンタルサーバーで十分」という結論のどちらかに行き着きがちです。この記事では、AWSでWordPressを立てる最短ルートと、そもそもAWSを選ぶべきかの判断基準を、料金の実額と公式手順に沿って整理します。

先に結論です。AWS(Amazon Web Services)はAmazonが提供する200種類以上のクラウドサービス群で、そのうちWordPressを動かす最短ルートが Amazon Lightsailです。EC2を素から組むのに比べ、WordPressが導入済みのイメージを選ぶだけでサーバーが立ち上がり、独自ドメイン・静的IP・SSL証明書までコンソールのウィザードで完結します。ただし無料枠は「3か月間」の期間限定で、永年無料ではありません。ここを誤解すると想定外の請求が来ます。


その用途、本当にAWSが必要か

手順に入る前に、ここを飛ばすと後悔します。AWSは「安いから」選ぶものではありません。運用の手間を自分で引き受ける代わりに、構成の自由度とスケールを得る選択です。

3つの選択肢を比較する

選択肢構築の手間運用で自分がやること向いているケース
レンタルサーバー最小(管理画面から数クリック)ほぼWordPressの更新のみ個人ブログ・小〜中規模のコーポレートサイト
Lightsail小(WordPress入りイメージを選ぶだけ)OS/ミドルウェアの更新、バックアップ設計AWS内で完結させたい・将来EC2へ移す前提
EC2大(OSからミドルウェアまで自分で構成)上記に加えて冗長化・監視・スケーリング設計大規模・複雑な要件・他AWSサービスと密結合

レンタルサーバーで足りるケース

次のどれかに当てはまるなら、AWSを選ぶ理由は薄いはずです。

  • サイトは1〜数本で、月間PVは数万規模まで
  • SSHやLinuxのコマンド操作に不安がある
  • OSやPHPのアップデートを自分で管理したくない
  • サーバーが落ちたときに電話やチャットで聞ける窓口が欲しい

レンタルサーバー側の具体的な選び方はConoHa WINGの特徴とメリットにまとめてあります。「クラウドのほうが上位」ではなく、運用体制に合うほうが正解です。

それでもAWSを選ぶ理由

逆に、次のような要件があるならAWSが効いてきます。

  • 他のAWSサービスと連携させたい(S3への画像退避、CloudFront配信、Lambdaでの処理など)
  • サーバー構成を自分で決めたい(PHPのバージョン、Webサーバー、キャッシュ層)
  • アクセス増に合わせて後から拡張したい(Lightsailで始めてEC2へ移行できる)
  • クライアント要件でAWS指定がある(受託開発では珍しくない)

料金と無料枠の正確な条件

ここが一番誤解されている部分です。Lightsailの無料枠は「3か月間」の期間限定で、条件も細かく決まっています。Amazon Lightsailの料金ページに明記されている内容を整理します。

無料枠は3か月間・1アカウント1バンドルまで

公式ページによると、無料枠の対象は次のバンドルで、3か月間無料です。適用は1アカウントにつき1バンドルのみ、かつ2021年7月8日以降に利用を開始したアカウントが対象と記載されています。

種別無料枠の対象バンドル(月額)
Linux/Unix(パブリックIPv4)5 USD / 7 USD / 12 USD
Linux/Unix(IPv6のみ)3.50 USD / 5 USD / 10 USD
Windows(パブリックIPv4)9.5 USD / 14 USD / 22 USD
データベースバンドル15 USD
コンテナサービス10 USD(マイクロ・1ノード)

最小構成である 3.50 USD/月(IPv6のみ)のスペックは、メモリ512MB・2vCPU・SSD 20GB・データ転送1TBです。日本語のWordPressを動かすにはメモリ512MBは心もとないため、実運用では上位のプランを検討してください。

「IPv6のみ」プランを選ぶときの注意

最安の3.50 USDプランはIPv6のみで、パブリックIPv4アドレスが付きません。IPv4しか使えない環境からはアクセスできないため、一般公開するサイトでこれを選ぶのは避けてください。学習用途と割り切る場合のみ有効です。公開サイトなら、パブリックIPv4が付く5 USD/月以上を選びます。

無料枠が切れた後に実際いくらかかるか

3か月を過ぎると、選んだバンドルの月額がそのまま課金されます。加えて、次の要素が上乗せされる点に注意してください。

  • スナップショット(バックアップ):自動スナップショットを有効にすると保存容量に応じて課金される
  • データ転送量の超過:バンドルに含まれる転送量を超えた分は従量課金
  • 未使用の静的IP:インスタンスに紐づいていない静的IPは課金対象になる
  • 為替:AWSの請求はUSD建てなので、円安局面では円換算額が上がる

無料枠の期間中に必ず請求アラートを設定しておいてください。AWS Budgetsで「月◯USDを超えたらメール通知」を1つ作っておくだけで、想定外の請求はほぼ防げます。


LightsailでWordPressを構築する手順

ここからは実作業です。手順はAWS公式のWordPressインスタンス構築ガイドに沿っています。現在のLightsailは「Set up your website(ウェブサイトのセットアップ)」ウィザードで、ドメイン・DNS・静的IP・SSL証明書をまとめて設定できます。個別に設定して回る必要はありません。

ステップ1|WordPressインスタンスを作成する

  1. Lightsailコンソールにサインインし、「インスタンスの作成」を選ぶ
  2. リージョンとアベイラビリティーゾーンを選ぶ(日本向けなら東京)
  3. プラットフォームで「Linux/Unix」、設計図(blueprint)で「WordPress」を選ぶ
  4. 設計図の提供元はLightsailを選ぶ(AWS公式が推奨している)
  5. インスタンスプランを選ぶ(公開サイトならパブリックIPv4付きの5 USD以上)
  6. インスタンス名を入力して「インスタンスの作成」

作成が終わったら、インスタンス管理ページ右上のパブリックIPv4アドレスをブラウザで開いてください。WordPressのテスト投稿が表示されれば、この時点でサーバー自体は動いています。

ステップ2|ドメイン・静的IP・SSLを一括設定する

インスタンス管理ページの「接続」タブ → 「ウェブサイトのセットアップ」から、ウィザードを開始します。順に次を設定します。

  1. ドメイン名の指定:Lightsail管理のドメイン、新規登録、他社で取得済みのドメインから選ぶ
  2. DNSの設定:LightsailのDNSゾーンを使うか、他社のDNSをそのまま使うかを選ぶ
  3. 静的IPアドレスの作成:名前を付けて作成する(後述のとおり必須)
  4. ドメインの割り当て:apexドメインとwwwサブドメインを割り当てる
  5. SSL/TLS証明書の作成:対象ドメインとメールアドレスを入力し、Let’s Encrypt証明書の設定を承認する

実行前に、インスタンスのファイアウォールでポート22・80・443がTCP接続を許可していることを確認してください。セットアップ中はこの3つが開いている必要があります。また設定完了まで最大15分かかり、その間はインスタンスを停止したり変更したりしてはいけません。進捗は「接続」タブで確認できます。

なお発行されるLet’s Encrypt証明書は60〜90日ごとに自動更新されるため、更新作業を自分で回す必要はありません。

ステップ3|管理画面のパスワードを取得してログインする

WordPress管理画面の初期パスワードはインスタンス内に保存されています。以前はSSHで接続してファイルを読む手順が一般的でしたが、現在はコンソールから取得できます

  1. インスタンス管理ページの「WordPress」パネルで「デフォルトパスワードを取得」を選ぶ
  2. 「CloudShellの起動」を選ぶと、画面下部にシェルが開く
  3. 提示されたコマンドをコピーしてCloudShellに貼り付けて実行する
  4. 表示されたパスワードを控える
  5. 「WordPress管理画面にアクセス」から http://パブリックIPv4アドレス/wp-admin を開く
  6. ユーザー名は user、パスワードは手順4で控えたものを入力してログイン

ログインできたら、最初にやることは管理者パスワードの変更です。初期ユーザー名が user で固定なのは広く知られているため、そのまま運用すると総当たり攻撃の的になります。


【検証】構築後に必ず確認する4項目

「サイトが表示された=完了」ではありません。ここで挙げる4項目を確認していないと、数日後に突然サイトが見えなくなるという事故が起きます。順に潰してください。

確認の手順と合否ライン

  1. 静的IPがアタッチされているか:Lightsailコンソールの「ネットワーキング」で、作成した静的IPがインスタンスに紐づいているかを見る。合否=インスタンスを一度停止→起動しても、パブリックIPが同じままであること
  2. DNSが正しく伝播しているか:ターミナルで nslookup 自分のドメイン を実行する。合否=返ってくるAレコードが、上で確認した静的IPと一致していること
  3. HTTPSで開くか、HTTPから転送されるかhttps://ドメイン で鍵マークが出るかを見る。さらに http://ドメイン を開いてHTTPSへ転送されるかも確認する。合否=両方のURLで最終的にHTTPSのページが表示されること
  4. WordPress側のURL設定がドメインになっているか:管理画面の「設定」→「一般」で、WordPressアドレスとサイトアドレスを見る。合否=IPアドレスではなく https://ドメイン になっていること

DNSの反映はすぐには終わりません。レコードを追加・変更した直後は世界中のDNSサーバーに伝わるまで時間がかかるため、nslookup や外部のDNS確認サービスで反映を確かめてから次に進んでください。

不合格だった場合の切り分け

症状疑うべき原因次の一手
再起動したらIPが変わった静的IPが未アタッチ静的IPを作成してインスタンスに紐づける。DNSのAレコードも更新する
ドメインで開けないがIPでは開けるDNSが未反映、またはAレコードの値が違うnslookupの結果と静的IPを突き合わせる
鍵マークが出ない・警告が出る証明書の発行が完了していないポート80/443の開放を確認し、ウィザードを再実行する
CSSが当たらず文字だけ表示されるサイトアドレスがIPのまま(混在コンテンツ)「設定」→「一般」でURLをHTTPSのドメインに修正する

4番目の「CSSが当たらない」は特に多い症状です。原因がサーバーではなくWordPress側の設定にあるケースも含め、切り分けの手順はデータベース接続エラーの対処法と併せて押さえておくと復旧が早くなります。


つまずきやすいポイント

公式手順どおりに進めても踏みやすい落とし穴を挙げます。いずれも「あとから気づく」タイプなので、先に知っておく価値があります。

静的IPを付け忘れ、再起動でサイトが見えなくなる

これが最頻の事故です。Lightsailインスタンスのデフォルトのパブリック IP アドレスは、インスタンスを停止して起動すると変わります。静的IPをアタッチしていれば停止・起動をしても同じIPのままですが、付け忘れているとDNSが古いIPを指したままになり、サイトが見えなくなります。

厄介なのは、構築直後は問題なく動くので気づけないことです。数週間後にメンテナンスでインスタンスを再起動した瞬間に発覚します。ウィザードで静的IPを作成していれば自動でアタッチされますが、手動で構築した場合は必ず確認してください。

「無料枠のつもり」で課金が始まる

無料枠は3か月間で終わります。カレンダーに終了日を入れておくか、AWS Budgetsで請求アラートを設定してください。特に見落としやすいのがインスタンスを削除したのに静的IPだけ残っているケースで、どのインスタンスにも紐づいていない静的IPは課金対象になります。使わなくなったリソースは、静的IP・スナップショット・DNSゾーンまで含めて消してください。

OSとミドルウェアの更新は自分の責任になる

レンタルサーバーとの最大の違いがここです。LightsailはOS・PHP・データベースの更新を代行してくれません。WordPress本体とプラグインの更新だけしていれば安全、という感覚のまま運用すると、OSの脆弱性が放置されます。

最低限、自動スナップショットを有効にして、更新前に必ず復元ポイントを作る運用にしてください。スナップショットには保存容量に応じた料金がかかりますが、復旧できない事故のコストに比べれば安いものです。WordPress運用全般の勘所はWordPress実践ガイドにまとめています。

メモリ512MBで日本語サイトを本番運用しようとする

最安プランのメモリは512MBです。WordPress本体は動きますが、プラグインを増やしたり画像を多用したりすると容易に足りなくなります。学習用なら最安で構いませんが、公開サイトはひとつ上のプランから始めるほうが結果的に安上がりです。表示速度の測り方はPageSpeed Insightsの見方と改善実務を参照してください。


後からEC2へ移行できるのか

「Lightsailで始めて、手狭になったらEC2へ」という道筋は実在します。Lightsailのスナップショットは、コンソールからAmazon EC2へエクスポートできます。エクスポートすると、EC2側にAMI(マシンイメージ)とEBSスナップショットが作成され、そこから新しいEC2インスタンスを起動できます。

スナップショットをEC2へエクスポートする流れ

  1. 移行したいインスタンスのスナップショットを作成する
  2. Lightsailコンソールの左メニューから「スナップショット」を開く
  3. 対象スナップショットの「アクション」メニューから「Amazon EC2にエクスポート」を選ぶ
  4. 「エクスポート」セクションで進捗(進行中/成功/失敗)を確認する
  5. 完了後、「EC2でインスタンスを作成」から新しいEC2インスタンスを起動する

移行前に知っておくべき制約

AWS公式のエクスポート手順に記載されている制約のうち、実務で効いてくるものを挙げます。

制約内容回避策
リージョンエクスポート先はLightsailと同じリージョンに限られる別リージョンへ移すなら、先にLightsail内でスナップショットをコピーしてからエクスポートする
IAM権限ルートユーザー以外が実行する場合、追加のIAMポリシーが必要管理者にサービスリンクロール作成の権限を付与してもらう
対象外のイメージcPanel & WHM(CentOS 7)のスナップショットはエクスポートできない該当する場合は手動移行を検討する
課金エクスポート後も元のLightsailスナップショットは保存料金がかかり続ける不要になった時点で削除する

つまり「Lightsailで始めると後戻りできない」ということはありません。まずは小さく始めて、必要になった時点でEC2へ移す判断ができます。ただしエクスポートには時間がかかり、移行後はセキュリティグループやEIPなどEC2側の設定を自分で組み直す必要がある点は見込んでおいてください。


まとめ

AWSでWordPressを動かす最短ルートはLightsailです。ただし「安いから」ではなく「運用を自分で引き受けられるか」で選ぶものだという点は最後まで意識してください。

  • 個人ブログや小〜中規模サイトなら、レンタルサーバーで十分なことが多い
  • 無料枠は3か月間・1アカウント1バンドル。永年無料ではない
  • 公開サイトはパブリックIPv4付きのプランを選ぶ(最安はIPv6のみ)
  • ドメイン・静的IP・SSLは「ウェブサイトのセットアップ」ウィザードで一括設定できる
  • 管理画面の初期ユーザー名は user。ログイン後すぐパスワードを変える
  • 構築後は「静的IP・DNS・HTTPS・サイトアドレス」の4点を必ず検証する
  • 手狭になったらスナップショットをEC2へエクスポートして移行できる(同一リージョン内)

まずは無料枠でインスタンスを1つ立て、上の4項目を自分の手で確認してみてください。ここまで通せれば、EC2へ移行する際も同じ勘所がそのまま使えます。


よくある質問(FAQ)

Q. AWSでWordPressを動かすのに一番簡単な方法は?

Amazon Lightsailを使う方法です。WordPressが導入済みの設計図(blueprint)を選ぶだけでサーバーが起動し、独自ドメイン・静的IP・Let’s Encryptによる SSL証明書までコンソールの「ウェブサイトのセットアップ」ウィザードで完結します。EC2にOSから構築する場合と比べて、必要な作業量が大きく減ります。

Q. Lightsailの無料枠は何か月使えますか?

AWS公式の料金ページによると3か月間です。対象は指定のバンドルのみで、1アカウントにつき1バンドル、かつ2021年7月8日以降に利用を開始したアカウントが対象と記載されています。永年無料ではないため、3か月を過ぎるとバンドルの月額がそのまま課金されます。AWS Budgetsで請求アラートを設定しておくことを推奨します。

Q. WordPress管理画面のユーザー名とパスワードはどこで確認しますか?

デフォルトのユーザー名は user です。パスワードはインスタンス管理ページの「WordPress」パネルで「デフォルトパスワードを取得」を選び、CloudShellを起動して提示されたコマンドを実行すると表示されます。ログインURLは http://パブリックIPv4アドレス/wp-admin です。ユーザー名が固定で知られているため、ログイン後は速やかにパスワードを変更してください。

Q. 静的IPは必ず設定しなければいけませんか?

公開サイトなら必須です。Lightsailインスタンスのデフォルトのパブリック IP アドレスは、インスタンスを停止して起動すると変わります。静的IPをアタッチしていないと、再起動のたびにDNSのAレコードを書き換える必要が生じ、書き換えるまでサイトが表示されません。なお、どのインスタンスにも紐づいていない静的IPは課金対象になるため、不要になったら削除してください。

Q. レンタルサーバーとAWS、どちらを選ぶべきですか?

サイトが数本まで、月間PVが数万規模、OSやPHPの更新を自分で管理したくないのであればレンタルサーバーが適しています。他のAWSサービスと連携させたい、サーバー構成を自分で決めたい、将来的にスケールさせる前提がある、クライアント要件でAWS指定がある、といった場合にAWSが有利です。AWSはOSとミドルウェアの更新が自己責任になる点を踏まえて判断してください。