作成したAWS環境で高可用性構成 というのが何か知りたい方は以下もご覧いただけますと幸いです。

Fargate + Single AZ RDSで構築する、高可用性&コスト最適化WordPress AWS構成

opticode.lab.com

なお、AWSプランや管理画面はよく変更されるため、2026年3月時点の設定であることをご理解ください。

CloudFrontとは？サービス内容を解説

CloudFrontは、AWS（Amazon Web Services）が提供するCDN（Content Delivery Network）サービスです。
簡単に言うと、「世界中に配置されたキャッシュサーバーを使って、Webサイトの画像や動画、HTMLなどのコンテンツをユーザーに素早く届ける仕組み」です。
競合サービスとしてはCloudflare、Akamai、Fastlyなどがありますが、AWSで環境を構築しているならCloudFront一択です。

CloudFrontを導入するメリット

導入すると以下のようなメリットがあります。

• ページキャッシュ：ページや画像などをキャッシュしてユーザーへ渡すため、オリジンであるWebサーバー等へのアクセスを抑えてコストダウン&負荷耐性が向上
• エッジロケーション：ユーザーと物理的に近いデータセンターにキャッシュを保持してユーザーへ渡すため、表示速度の向上につながる
• AWSコンポーネントとの親和性：AWS連携が容易でサービス間でのデータ転送量が安い
• 無料枠：小規模なサイトであれば実質無料で使用できることも珍しくない
• セキュリティ向上：CloudFrontが間に入りユーザーがWebサーバーを直接見ないためセキュリティが向上・WAF設定も可能

無料枠を超えるアクセス数の多いサイトは費用がかかりますが、高スペックなサーバーを動かし続けるより安く済む場合が多いでしょう。

WordPressでCloudFrontを使用する場合の注意点

メリットは大きいですが、注意点もあります。

• ログイン状態のページがキャッシュされる
• カスタムポリシーを使用できるプランに制限がある

ログイン状態のページがキャッシュされる問題と解消方法

CloudFrontはユーザーがページへアクセスした場合に、
キャッシュがあればキャッシュを返す
キャッシュが無ければオリジンからページを取得しキャッシュを生成
という動作を行います。

そこで問題になるのが、ログイン状態のユーザーです。
WordPressでログインをしている場合、ページ上部の admin bar のようにWordPressログイン状態にのみ表示される要素が存在するため、これをCloudFrontがキャッシュしてしまうと一般ユーザーにも admin bar が表示されるような事態となってしまいます。

つまり、WordPressにログインしたユーザーをキャッシュ対象外にする必要があります。

設定にはCloudFrontのカスタムポリシー作成が必須となりますので、以下の手順でカスタムポリシーを作成のうえCloudFrontのビヘイビアに登録します。

• AWSコンソールからCloudFrontの管理画面を開き、左メニューからポリシーの管理ページを表示

• ページ下部の「キャッシュポリシーを作成」
• cookie「指定された cookie を含める」を選択し以下の3つを追加しポリシーを作成する
  comment_author_*、wp-postpass_*、wordpress_logged_in_*

• CloudFrontのディストリビューション、ビヘイビア設定の「デフォルト(*)」を選択し編集
• キャッシュポリシーで作成したカスタムポリシーを選択、オリジンリクエストポリシーをAllViewerに設定し保存

これはWordPressのログインセッションに使用するcookieを持っていればログインユーザーとして扱い、ページをキャッシュしない&キャッシュを表示しない という設定です。

カスタムポリシーを使用できるプランに制限がある

なんと、CloudFrontのディストリビューションが定額料金プランのFreeプラン(0$)・Proプラン(月額15$)はカスタムポリシーが選択できず、ビジネスプラン(月額200$)以上を選べという案内が表示されます。
学習目的や収益の少ないサイトでこの負担は現実的ではありません。

しかし、従量課金プラン(Pay as you go) を使用すればビジネスプランでなくともカスタムポリシーを使用することが可能です。
従量課金プランでも一定の範囲内であれば無料で使用が可能ですので、学習用や小規模なサイトであれば従量課金プランで始めて、アクセス数が増え収益が出るならビジネスプランへの変更を検討するのがよさそうです。

無料枠については今後変更される可能性があるため、AWS公式の情報をご確認のうえ検討してください。

まとめ

最初は定額プランのFreeプランで設定していたのでカスタムポリシーが設定できず手間取りました。
学習目的でお金をかけたくなかったため、従量課金プランでも無料枠があってくれてラッキーでした。

とはいえCloudFront自体はかなり安価なので、よほど記事がバズったりしなければ高額な請求などは無いかなとは思います。

1. 要件

• AWS学習を目的としてAWS Lightsail環境の当サイトをAWS高可用性構成で再現する。
• あくまでも学習のため、削れるコストは可能な限り削る。
• Lightsail環境のデータベースやメディアを全て移行する。

可用性とコストのどちらを優先するかは都度判断。

2. 構成図の全体像と設計思想

この構成図は、WordPressをAWS上に構築するための、疎結合（Decoupled）なモダン・アーキテクチャを示しています。

この構成の肝となる3つのポイント

• 高可用性（High Availability）: CloudFront、ALB、FargateマルチAZ展開
• コスト最適化（Cost-Optimized）:Fargate Spot、Single AZ RDS
• ステートレスなコンピュート層：Fargateコンテナを使い、テーマ、プラグイン、メディアファイルを外部サービスへ外部化

3. 各コンポーネントの詳細解説：データの流れに沿って

データの流れ（フロントエンドからバックエンドへ）に沿って、各コンポーネントの役割と設計意図を解説します。

3-1. フロントエンド（VPC外サービス）：配信の効率化と可用性

ユーザーアクセスはまず、VPC（Virtual Private Cloud）の外にあるグローバルサービスで受けます。

• AWS Route 53 (DNS): DNSルーティングを行います。
• AWS CloudFront (CDN): データの配信の肝です。
• 静的コンテンツ origin: Amazon S3 から画像やCSS/JSをキャッシュして高速配信。
• 動的コンテンツ origin: ALBを経由してWordPress（Fargate）に接続。
• Amazon S3: WordPressのメディアファイル（アップロード画像など）を保存するストレージ。静的ファイルの配信はここを起点に行います。

設計のポイント：
静的ファイルをCloudFront/S3へ外部化することで、Fargateコンテナの負荷を大幅に軽減し、かつユーザーの体感速度を向上させています。

3-2. VPC内ネットワーク（Subnet設計）：疎結合と可用性の担保

VPC内は、高可用性を実現するために2つのアベイラビリティゾーン（AZ-a、AZ-b）にまたがって設計しています。

• Public Subnet: WordPressが動作するFargateコンテナを配置。
• Private Subnet: データベース（RDS）と、共有ストレージのマウントターゲット（EFS）を配置。外部からの直接アクセスを遮断し、セキュアに守ります。

コスト削減のポイント：
FargateコンテナはPrivate Subnet内に配置するとセキュリティを向上させることが可能ですが、NATゲートウェイ（月額2,000円ほど）が必要となります。
今回はコスト削減のためFargateコンテナはPublic Subnetに配置し、インバンドアクセスをALBに限定することでセキュリティを担保しています。

3-3. ロードバランサー（ALB）：マルチAZ可用性の鍵

• ALB (Application Load Balancer): Public Subnetにまたがって配置。CloudFrontからの動的リクエストを受け取り、背後のFargateタスクへ負荷分散します。

高可用性のポイント：
ALBは、AZ-aとAZ-bの両方のサブネットを監視し、正常なタスクにのみリクエストを振るため、どちらかのAZで障害が発生してもサイトは落ちません。

3-4. コンピュート層（Fargate）：ステートレス化とコスト最適化

WordPressが動作するコンピュート層は、EC2ではなくマネージドなコンテナサービスであるAWS Fargateを利用します。EC2のOSパッチ当てなどの運用負荷を軽減できます。

この構成の最大のポイントは、FargateのAutoScalingによる高可用性の実現です。

• On-Demand Base Task: 常時1台起動する、サイトの「生命線」となるベースタスク。安定性を確保。
• Spot Task: 負荷に応じて追加されるタスク。負荷低減により自動で停止。

コスト削減のポイント：
今回は学習目的のため、スケールアウトで追加される2台目以降のFargateはSpot Taskを採用しています。
Spot Taskはオンデマンドと比較して最大80-90%引きと安価に使用可能ですが、AWSのリソースが枯渇するとタスクが中断されるデメリットがあります。実際の案件ではオンデマンド：Spot は 50:50 の程度の比率が現実的です。

学習のポイント：
Fargateコンテナをステートレス化（ファイルはEFS、メディアはS3、DBはRDSへ外部化）しているため、Spot Task の突然の中断にも耐えられる設計になっています。

3-5. データベース層（RDS）：コスト優先のSingle AZ構成

• Amazon RDS for MySQL [Single AZ]: データベースはプライベートサブネットに配置。Fargateからの接続のみを許可。

コストと可用性のトレードオフ：
高可用性を目指すならRDSもマルチAZ（Multi-AZ）にすべきですが、今回は「学習目的」であり「削れるコストは削る」という方針のため、あえてSingle AZ構成にしています。これにより、RDSのコストを大幅に削減しています。
コスト度外視で高可用性・耐久性・性能を求める場合はAWS Auroraも使用可能です。

3-6. ストレージ層（EFS）：Fargateステートレス化の肝

• Amazon EFS (Elastic File System): Fargateコンテナは起動・終了を繰り返すため、コンテナ内にテーマ、プラグイン、設定ファイルを保存できません。これらを複数のFargateコンテナ間で共有・保存するための共有ストレージです。
• EFS Mount Target: 各AZのプライベートサブネットにマウントターゲットを配置し、Fargateからマウントします。

疎結合設計のポイント：
Lightsailでは1つのVPS内にあったすべてのファイルを、Fargate、RDS、EFS、S3へと外部化した疎結合設計にすることで、スケーラビリティと可用性を実現しています。

4. 既存Lightsail環境からの移行手順

Lightsailの環境（WordPress Certified by Bitnami）からの移行は、以下のようなステップになります。

1. 各コンポーネントの作成
2. 中心となるFargateとRDS,EFS,ALBを接続
3. LightsailのMySQLからデータをエクスポート（mysqldump）
4. RDSへデータをインポート（Fargate経由）
5. テーマファイルをFargate WordPressの管理画面からアップロード（マウント済みのEFSに自動アップロード）
6. プラグインをFargate WordPressの管理画面からインストール&有効化
7. LightsailのWordPressからwp-content/uploadsディレクトリをS3へコピー
8. Fargate WordPressメディアアップロードから画像がS3にアップされるように接続
9. CloudFrontとALB,S3を接続し、動的ページをALB、静的ファイルをS3から取得するようビヘイビア設定
10. 動作検証（WordPress動作やスケールアウトなど）
11. WordPressサイトURLやDB内URLを本番ドメインに切り替え
12. Route 53でDNSを切り替え
13. DNS浸透待ちで数日経過後にLightsail停止

このプロセスを通じて、Lightsailという「オールインワン」のシンプルさから、AWSの基本サービスの「疎結合設計」への変化を深く理解できます。

5. この構成を作るにあたって学んだこと

以下のAWS技術と設計思想を理解し、実際に作成できることの証明ができます。

• 疎結合設計（Decoupled Architecture）: Web、DB、Storage、Global Servicesの分離。
• 高可用性（High Availability）: CloudFront、ALB、マルチAZネットワーク設計の理解。
• コスト最適化（Cost-Optimized）: Fargate Spot、Single AZ RDSの使い分け。
• AWSの基本サービスの理解: Route 53, CloudFront, ACM, ALB, VPC (Subnet/SG), Fargate, RDS, EFS, S3
• コンテナ技術: Fargateの利用とコンテナのステートレス化。
• トレードオフの理解: 学習目的として可用性とコストのバランスを意識した設計（例：RDS Single AZ）。

5-1. 苦労したポイント

• CloudFrontがWordPressログインユーザーのアクセスをキャッシュしてしまう：
  CloudFrontのキャッシュポリシーを変更し、WordPressログインを判別するCookieを持ったアクセスはキャッシュさせない
• Fargateコンテナの操作：
  EFSマウントしたファイル以外は保持されず、デフォルトだと機能が最小限でzip解凍すらできなかった
• RDSが直接操作不可：
  RDSがPrivate Subnet内に存在するため直接接続ができずFargate経由で接続する必要があった
• エラー原因の特定：
  複数のコンポーネントに跨るため、どこにエラーがあったか特定が難しい
• 料金が高い：
  可能な限りコストを削減するための構成かつ安価なプランを使用したが、それでも月8,000円ほどかかる見込み
  RDS無料枠はAWSアカウントを作成して1年間のみなのが痛い

6. まとめと今後の展望

この構成は、学習用としてはかなり実戦的なWordPress環境が作成できたのではと思います。Lightsailからのステップアップとして、Fargateや疎結合設計を学ぶのに最適でした。

ただし、小規模なブログを運用するには過剰なスペックかつ高価です。おとなしく国内レンタルサーバー + Cloudflare を使用した安価な環境が現実的でしょう。
僕はしばらく学習に使用する際にのみ起動し、Lightsailでの運用を継続しようと思います。

今後の展望としては、以下を想定しています。

• CloudFrontのより詳細なキャッシュ設定
• IaC を使用したstg環境の作成
• GitHub からの CI/CD
• Lambda@Edgeを使用したS3画像ファイルのWebP,AVIF生成自動化

ご相談・ご依頼お待ちしております。

お問い合わせはこちら