AWSの学習を始めると、まず頭に浮かぶのが「今 WordPress で書いているこのブログも AWS に載せたほうがいいのでは？」という疑問です。私もそうでした。
この記事では、WordPress のブログを AWS で動かす方法を 4 つに整理して、費用・投稿のしやすさ・保守の手間・学べる AWS サービスで比べます。そして最後に、比べた上で私が今はブログを AWS に移さず、レンタルサーバーに残すと決めた理由を書きます。「AWS を学ぶ＝全部 AWS に移す」ではない、という話です。
※料金は 2026 年 10 月時点の公式ページの数値です。最新の情報は記事末尾のリンクで確認してください。
CONTENTS目次
4 つの方法を一覧で比較
WordPress のブログを AWS で動かす、と一口に言っても「WordPress をそのまま動かす」のか「書く道具だけ残して配信を変える」のか「WordPress をやめる」のかで、まったく別の話になります。
| 方法 | 記事の書き方 | 月額の目安 | 保守の手間 | 学べる AWS サービス | 向いている人 |
|---|---|---|---|---|---|
| ① Lightsail＋WordPress | 今と同じ WordPress の管理画面 | 5〜7 USD（約 800〜1,100 円） | 大。OS・PHP・WordPress の更新とバックアップを自分で | Lightsail（EC2 の簡易版）、DNS | 書き心地を変えたくない人 |
| ② WordPress を静的化して S3＋CloudFront | WordPress で書いて HTML に書き出す（手元の環境でも可） | 100 円前後 | 中。書き出しと転送の手順が毎回入る | S3、CloudFront、ACM、Route 53 | 安く・速く・安全に配信したい人 |
| ③ microCMS＋Astro＋Amplify Hosting | microCMS の管理画面（ブラウザ） | 無料枠内なら 0〜数百円 | 小。サーバーの保守なし。デザインはコードで管理 | Amplify Hosting、Route 53、（裏で S3・CloudFront） | React・TypeScript が書けて、書きやすさと自由さを両立したい人 |
| ④ Markdown＋Astro／Next.js＋Amplify Hosting | Markdown を GitHub に push | 無料枠内なら 0〜数百円 | 小。③と同じ | ③と同じ | エディタで書くのが苦にならない人 |
月額の目安は、個人ブログ程度のアクセス量を想定しています。順に見ていきます。
① Lightsail に WordPress をそのまま載せる
Lightsail（ライトセイル）は、EC2 を簡単にしたサービスです。WordPress 入りのサーバーがワンクリックで立ち上がり、料金も月額固定なので、AWS の中ではレンタルサーバーに一番近い感覚で使えます。
料金は Linux の最小プランが 5 USD/月（メモリ 0.5GB）、次が 7 USD/月（メモリ 1GB）。WordPress を安定して動かすなら 1GB のプランが現実的です。どちらも最初の 3 か月は無料で使えます。
いちばんの注意点は、保守が全部自分の仕事になることです。レンタルサーバーでは会社がやってくれていた OS や PHP の更新、バックアップ、セキュリティ対策を、自分で行います。WordPress の管理画面がそのまま使えるのは楽ですが、「サーバーを 1 台持つ」責任がついてきます。
学べる AWS の範囲は狭めです。Lightsail は AWS の中でも独立した作りで、VPC や IAM の設計に触れる機会がほとんどありません。「AWS の実務力をつける」目的には、少し物足りないと感じました。
② WordPress を静的化して S3＋CloudFront で配信する
WordPress を「書く道具」として手元やサーバーに残し、公開するのは書き出した HTML だけ、という方法です。書き出しには静的化プラグインを使います。
配信側は、AWS で静的サイトを公開する基本の構成そのものです。
- S3：HTML・CSS・画像を置く
- CloudFront：世界中の拠点から高速に配信し、HTTPS をかける
- ACM：SSL 証明書を無料で発行する
- Route 53：独自ドメインを結びつける（今の DNS をそのまま使う手もあります）
費用はとても安く済みます。S3 の保存料は個人ブログの容量なら数十円、CloudFront は料金ページに月額 0 USD の無料プラン（データ転送 100GB・100 万リクエストまで）が用意されています。Route 53 のホストゾーンは 1 つ 0.50 USD/月。合わせても月 100 円前後です。
公開したものは静的な HTML だけなので、WordPress 本体がインターネットにさらされず、セキュリティ面でも強くなります。一方で、コメント機能やお問い合わせフォームのような動的な部分は別の仕組みが必要になり、記事を書くたびに「書き出して転送する」手順が入ります。
この構成は、第 1 回で「最初に作るもの」として挙げた構成と同じです。ブログの引っ越しとは別に、AWS 学習の最初の一歩として組んでみる価値があります。
③ ヘッドレス CMS（microCMS）＋Astro を Amplify Hosting で公開する
WordPress をやめて、記事の管理を microCMS のようなヘッドレス CMS に、見た目の部分を Astro や Next.js に分ける方法です。ブラウザの管理画面で記事を書く点は WordPress と同じで、公開すると自動でサイトが再ビルドされます。
Amplify Hosting は、GitHub のリポジトリをつなぐだけで、ビルドから配信までを自動でやってくれるサービスです。裏側では S3 や CloudFront にあたる仕組みが動いていますが、自分で設定する必要はありません。
費用
Amplify Hosting は、最初の 12 か月は無料枠（ビルド 1,000 分/月、ストレージ 5GB、データ転送 15GB/月、50 万リクエスト/月）があります。その後はビルド 1 分 0.01 USD、ストレージ 0.023 USD/GB/月、データ転送 0.15 USD/GB。個人ブログなら月に数百円を超えることはまずありません。
microCMS は Hobby プランが 0 円でクレジットカードも不要です。API は 5 個まで、メンバー 3 人まで、コンテンツ 10,000 件、データ転送 20GB/月。ブログなら「記事」「カテゴリ」「タグ」「プロフィール」程度で API は 5 個に収まります。
気をつける点
- データ転送量：Hobby の 20GB/月を超えると API が止まります。ただし Astro で静的ビルドすれば microCMS へのアクセスはビルド時だけ。記事中の画像を microCMS の URL のまま表示すると閲覧のたびに転送量を使うので、アクセスが増えたらビルド時に画像を取り込む設計にします
- 使える機能：CSV 出力やファイルのアップロードなどは Team プラン（4,900 円/月〜）から。PDF の添付は S3 に置いてリンクする形にします
- 既存記事の移行：WordPress の記事を microCMS に入れ直す作業が発生します。記事数が多いほど重い
React・TypeScript で開発している人には、いちばん相性のよい方法です。デザインの自由度が高く、サーバーの保守がなく、学んだことがそのまま Web アプリ開発に活きます。
④ Markdown＋Astro／Next.js を Amplify Hosting で公開する
③から microCMS を外し、記事を Markdown ファイルとして GitHub に置く方法です。費用は③と同じで、CMS の制限もなくなります。
ただし「記事を書く＝エディタで Markdown を書いて push する」になるので、ブラウザの管理画面で書きたい人には向きません。画像の管理も自分で行います。開発者がメモを公開する用途には最適ですが、「書くことに集中したい」ブログには③のほうが楽だと思います。
独自ドメインとメールはどうなるか
どの方法でも、今の独自ドメインはそのまま使えます。やり方は 2 つです。
| 方法 | やること | 向いている場合 |
|---|---|---|
| 今の会社で DNS 管理を続ける | 今の管理画面で、DNS レコードを AWS 側（CloudFront や Amplify）に向ける | メールもその会社で使っている。変更を最小にしたい |
| DNS だけ Route 53 に移す | Route 53 でホストゾーンを作り、ドメイン会社でネームサーバーを変更する | AWS 側で完結させたい。www なしのドメインも AWS の画面で設定したい |
移行でいちばん事故が起きやすいのはメールです。そのドメインでメールを使っているなら、MX レコードや SPF・DKIM・DMARC の設定を Route 53 に写してからネームサーバーを切り替えないと、メールが届かなくなります。サイトは仮の URL で完成させ、最後に DNS を切り替え、しばらく旧環境を残しておくのが安全です。記事の URL が変わる場合は、旧 URL からの転送（リダイレクト）も用意します。
私の結論：今は Xserver に残す
ここまで比べた上で、私はこのブログを当面は AWS に移さず、Xserver の WordPress のまま運用すると決めました。理由は 3 つです。
理由 1：単価に効くのは「アプリを AWS で動かした実績」
私が AWS を学ぶ目的は、Web アプリケーションを AWS で設計・運用できるようになり、フリーランスとしての単価を上げることです。評価されるのは、データベース・認証・コンテナ・インフラのコード化といったアプリ側の実績であって、WordPress を別のサーバーに載せ替えたことではありません。実績づくりは、実際に運用している Web アプリの AWS 移行で進めることにしました。
理由 2：ブログの移行作業の大半は、AWS ともアプリ開発とも関係が薄い
実際に移行計画を立ててみると、作業の中身はメールの移行、ネームサーバーの委任、DMARC の設定、セキュリティプラグインの設定の引き継ぎ、といったものがほとんどでした。やればできますが、そこで得られるのは「引っ越しの経験」で、学びたい AWS の設計力ではありませんでした。
理由 3：今のレンタルサーバーで困っていない
表示速度にも安定性にも問題がなく、月額も個人で負担できる範囲です。移す理由が「実績づくり」しかないなら、その実績はアプリ側で作ればよい、という結論になりました。
「AWS を学ぶなら全部 AWS に移すべき」と考えがちですが、何を AWS に載せるかは、目的から逆算して決めるのがよいと思います。ブログは書くことが目的なので、書きやすい場所に置いておく。それも一つの設計判断です。
それでも移すなら、私は③を選ぶ
将来ブログを移すことになったら、私は③の microCMS＋Astro＋Amplify Hosting を選びます。ブラウザから投稿できて、デザインは自由、サーバーの保守がなく、普段使っている React・TypeScript の延長で作れるからです。手順は「microCMS に API を作る → Astro で記事一覧と詳細ページを作る → GitHub に push → Amplify Hosting でつなぐ → 動作確認後に DNS を切り替える」の流れになります。
試験のツボ
AWS 認定試験（Cloud Practitioner / Solutions Architect – Associate）の観点で、この記事に出てきたサービスの押さえどころです。
- Lightsail と EC2 の違い：Lightsail は月額固定・簡単な構成向け。細かいネットワークやスケーリングの制御が必要なら EC2。試験では「最小限の管理で WordPress を動かしたい」なら Lightsail が答えになりやすい
- S3 の静的ウェブサイトホスティング：S3 単体でも静的サイトを公開できるが、HTTPS と独自ドメインを使うなら CloudFront を前に置く。S3 を公開設定にせず、CloudFront からだけ読めるようにする仕組み（OAC）が推奨
- CloudFront の役割：エッジロケーションからのキャッシュ配信で、遅延の削減とオリジンの負荷軽減。ACM の証明書をバージニア北部（us-east-1）で作る必要がある
- Route 53 のホストゾーン：ドメインの DNS レコードをまとめたもの。ドメインの「登録」と「DNS 管理」は別の機能で、DNS 管理だけ Route 53 に移すことができる
- マネージドサービスの考え方：Amplify Hosting や microCMS のように「運用を任せる」ほど自分の責任範囲は減る。責任共有モデルで、どこまでが自分の責任かを説明できるようにしておく
まとめ
- WordPress のブログを AWS で動かす方法は 4 つ。「そのまま載せる（Lightsail）」「静的化して配信（S3＋CloudFront）」「ヘッドレス CMS に移る（microCMS＋Astro＋Amplify）」「Markdown で書く（Astro／Next.js＋Amplify）」
- 費用はどれも月数百円以下に収まるが、保守の手間と学べる範囲が大きく違う
- 独自ドメインは引き継げる。事故が起きやすいのはメールの DNS 設定
- 私は、AWS の実績はアプリ側で作ると決め、ブログは今のレンタルサーバーに残した。何を AWS に載せるかは目的から逆算して決める
次回は、予告どおり AWS アカウントの作成と初期設定（MFA・管理者ユーザー・Budgets）、そして練習用の小さなサイトを S3＋CloudFront で公開するまでを、実際にやった記録として書きます。このブログやホームページを移すわけではなく、学習用のサブドメインで試します。
参考にした公式情報（2026 年 10 月時点）：
