ここまで全4章にわたり、Active-Active 構成の設計思想、アーキテクチャの全体像、フェイルオーバー試験の結果、そして構築中に踏んだ実践的なハマりどころを紹介してきました。

本章では、これまでに解説してきたマルチリージョンの基本構成をベースとして、本番環境（プロダクション）への導入を見据えたさらなる最適化のアプローチについて解説します。

マルチリージョン構成は、事業のフェーズや要件に応じて柔軟に拡張していくことが可能です。ここでは、セキュリティ、パフォーマンス、および運用自動化の観点から、実際のエンタープライズ環境で推奨される具体的なアップグレードパスを4つ紹介します。コアとなるマルチリージョン設計（第1〜4章で解説）は維持したまま、要件と予算に応じて独立して適用できる選択肢としてご参照ください。

1. CloudFront + WAF による公開エンドポイントの保護

現状の課題

今回の構成では、ALB（Application Load Balancer）をパブリックサブネットに配置し、インターネットに直接公開しています。Route 53 のレイテンシーベースルーティングによって最寄りのリージョンの ALB へ誘導する設計ですが、ALB のエンドポイントが外部から直接解決できる状態にあるため、以下の課題があります。

• WAF を後段に追加したとしても、ALB の IP アドレスを知っている攻撃者は WAF を迂回して直接アクセスできてしまう
• DDoS 対策が ALB 単体に依存しており、AWS Shield Standard のみの防御に留まる

推奨構成: CloudFront を前段に配置し、ALB への直接アクセスを遮断する

本番環境では、CloudFront を公開エンドポイントの前段に配置することを強く推奨します。CloudFront がエッジロケーションで SSL 終端・キャッシュ・AWS WAF による脅威防御を担い、オリジン（ALB）への不正アクセスを遮断します。

CloudFront と ALB を組み合わせる際、ALB への直接アクセスを防ぐアプローチとして主に2つの方法があります。

案A: マネージドプレフィックスリストによる制限（既存構成への適用が容易）

ALB をパブリックサブネットに置いたまま、Security Group のインバウンドルールに CloudFront が使用する IP レンジを管理した 「AWS マネージドプレフィックスリスト（com.amazonaws.global.cloudfront.origin-facing）」 を指定する方法です。CloudFront 以外の IP からの直接アクセスをネットワークレベルで遮断できます。構成変更の影響範囲が小さく、既存の ALB をパブリックサブネットに維持したまま適用できるため、移行コストを最小化できます。

案B: CloudFrontのVPCオリジン機能（より高いセキュリティ水準）

2024年末に一般提供（GA）された 「VPCオリジン」 機能を使用する方法です。ALB をプライベートサブネットに配置し、CloudFront からの通信のみを AWS のプライベートネットワーク経由で到達させる仕組みです。ALB のエンドポイントがインターネット上に公開されないため、よりセキュアな構成を実現できます。

どちらの方式を選択するかは、既存構成への移行コストやセキュリティ要件に応じて判断してください。なお、CloudFront を導入することで、5.2 で説明するメディア配信の最適化とも相乗効果があります。

2. メディア配信の「S3 オフロード」と CloudFront による最適化

「S3 オフロード」とは、本来アプリケーションサーバー（今回の構成では EC2 と EFS）が担っていた画像や動画などの静的ファイルの保存・配信処理を、Amazon S3 に切り離して（オフロードして）、サーバーの負荷を軽減するアーキテクチャパターンのことです。

現状の課題

今回の構成では、WordPress がアップロードしたメディアファイル（画像・動画等）は EFS 上に保存されており、ユーザーへの配信は ALB 経由で行われています。この経路は EFS → PHP（WordPress） → ALB → ユーザー という流れになりますが、以下の問題があります。

• 効率の問題：
  EFS はマウントしたインスタンスがファイルシステムとして使用することには優れていますが、HTTP による大量の静的コンテンツ配信には向いていません。バイナリファイルの配信ごとに PHP プロセスを経由するため、CPU・メモリ・ネットワーク帯域を過剰に消費することになります。
• スケーラビリティの問題：
  トラフィックが増加したとき、EC2 インスタンスのスペック（または台数）を増やしても、メディア配信のオーバーヘッドが高いままであるためスケーリングの効率が悪くなります。

推奨構成: S3 をメディア配信の基盤とし、CloudFront で CDN 化する

WordPress の WP Offload Media 等のプラグインを導入し、アップロードされたメディアを自動的に S3 バケットへ転送する設計への移行は、システム全体のスケーラビリティとパフォーマンスを向上させるための有効なアプローチとなります。CloudFront を S3 オリジンとして連携させることで、ユーザーに最も近い配信拠点（エッジロケーション）からキャッシュが返されるようになり、画像などのメディアファイルの表示速度を大幅に向上させることができます。

この構成にすることで、EFS 上のアプリケーションファイル（PHP/HTML/CSS/JavaScript）への読み書きと、S3 上の静的コンテンツ（画像・動画）の配信を完全に分離できます。EC2 インスタンスへのメディア配信負荷が解消され、Web サーバーはビジネスロジックの処理に専念できるようになります。

3. EFS 双方向同期の運用上の課題と代替案

現状の設計とその限界

今回の構成では、EFS Replication を用いて東京（プライマリ）から大阪（レプリカ）へ一方向のレプリケーションを行っています。

Active-Active 構成では、本来であれば両リージョンで同時に書き込みが発生しますが、今回はその問題を以下の設計で回避しています。

• データベースへの書き込み：
  Aurora Global DB の Write Forwarding 機能により、大阪リージョンからの書き込みも東京プライマリへ転送する
• ファイルの書き込み（WordPress のメディアアップロード等）：
  現状では大阪リージョンで発生した書き込みは大阪の EFS に書き込まれますが、レプリケーションは「東京 → 大阪」の一方向であるため、大阪で新規アップロードされたファイルが東京に反映されない設計上の矛盾があります

また、障害時に大阪 EFS をプライマリに昇格させる際は、EFS Replication のレプリケーション設定を削除する操作が必要です。これが自動化されていないことも、運用上のリスクとなります（詳細は第6章で触れます）。

改善アプローチ

この設計上の矛盾を解消するアプローチとして、以下の2つが考えられます。

AWS DataSync の活用

AWS DataSync を使用することで、EFS 間のスケジュール同期や、柔軟なフィルタリング設定が可能になります。EFS Replication と比べてよりきめ細かな制御ができる反面、完全なリアルタイム同期ではないため、用途に応じた許容レイテンシの見極めが必要です。

S3 への完全移行（前述 2. の拡張）

前述の「S3 オフロード」と組み合わせる形で、WordPress のメディアファイルをはじめとするユーザー生成コンテンツをすべて S3 で管理する設計に移行することが、最も抜本的な解決策です。S3 は標準でクロスリージョンレプリケーション（CRR）をサポートしており、Active-Active 構成のファイルストレージとして高い適合性を持ちます。EFS への依存を最小化し、読み書き性能やスケーラビリティの課題も同時に解消できます。

4. IaC によるインフラ管理の必須性と「完全自動化」へのステップアップ

マルチリージョン構成において IaC はほぼ必須

本環境では CloudFormation による IaC を部分的に活用しましたが、一部の設定（ALB のリスナールール調整、Route 53 レコードの修正等）は手動で行いました。

しかし、本番環境への適用を考えると、この「部分的な手動管理」にはリスクが伴います。本構成のようなマルチリージョン・マルチサービスの複雑なアーキテクチャでは、管理対象リソースがシングルリージョン構成の2倍以上に膨れ上がります。これだけの規模を手動で管理し続けることは、ドリフト（コードと実機の乖離）を発生させ、やがて「誰も全貌を把握できない」という状態への劣化に繋がりかねません。

そのため、このレベルの複雑さを持つ構成では、IaC の導入は「あった方が良い」ではなく、「なければ運用が成立しない」という、ほぼ必須の前提条件と言えます。

「完全自動化」によるさらなる安全性・安定性の確保

部分的な IaC 化から一歩進めた「完全自動化」を目指すことで、インフラ管理の安全性と安定性をさらに高めることができます。

たとえば、Terraform の マルチプロバイダー設定 を活用し、東京・大阪の両リージョンをコード上で一元管理します。そして GitHub Actions 等の CI/CD パイプラインと連携させ、terraform plan → apply をワークフローとして自動化し、Pull Request ベースのレビュー・承認フロー（GitOps）を導入することで、以下のような効果が得られます。

• 人的ミスの排除：
  レビュープロセスがコードの変更ゲートとして機能し、意図しない変更が本番環境に適用されることを防ぐ
• 構成ドリフトの早期検知：
  第4章で取り上げた「AMI参照のサイレントな不一致」のような問題も、IaC の徹底と plan の定期実行を組み合わせることで、実際に障害が起きる前に検知できるようになる
• 再構築コストの最小化：
  IaC でインフラがコード化されていれば、リージョン障害等の大規模障害発生時でも、別リージョンへの再構築をコマンド一発で再現できる

まとめ

本章で取り上げた4つの課題をまとめると以下のようになります。

いずれの課題も、コアとなる Active-Active 構成（第1〜4章で解説）を維持したまま、独立して段階的に適用できるアップグレードパスです。一度にすべてを実装する必要はなく、自組織の優先課題や予算に応じて着手する順序を判断してください。