はじめに

AWS上でウェブサイトを作成し、公開するとします。
一般公開の用途で、最低限の冗長性を持ったサイトを作成すると想定して、AWS構成を考えてみました。

①VPC

とりあえずVPCを一つ作り、その中にサブネットを2つ作ります。
RDS作成時にAZの異なるサブネットを2つ指定しなければいけないため、AZのリージョンは違うものにしておきます。それぞれのリージョンに、EC2一台とサブネットが所属する形になります。
そのAZのデータセンタが津波で壊れたとしても、別のAZに存在するもう一台のEC2が稼働し、RDSについてもマルチAZ構成のため、片方のAZが生きているため稼働が可能です。
※東京では現在3つのリージョンが選択可能1(ap-northeast-1a、ap-northeast-1c、ap-northeast-1d)。

②EC2

OSはAmazon linux2想定。インスタンスタイプはt3系が多いイメージです。
あとから上のグレードのインスタンスに変更することも可能です。
インスタンス作成時はルートボリュームを8GBから30GBまで無料で大きくできます。

③RDS

EC2と同じく、t3-から始まるインスタンスタイプにすることが多いイメージです
可用性を持つため、インスタンス作成時にデフォルトでマルチAZ指定が有効になってます。
=2つのサブネット上に配置しなければいけない且つ対象のサブネットが別のAZでなければいけないません。

④ALB, Gloabal Accelerator

ALBにてhttpでリクエストはhttpsにリダイレクトするルールや、通常のリクエストはEC22台が入ったターゲットグループに送るルールを導入します。ALBのIPをDNS公開しても、定期的にアドレスが変わってしまうため、Global Acceleratorを挟み、Global AcceleratorのIPを公開します。この場合だと確かIPが勝手に変わらなかった気がします…

⑤Cloudwatch

AWSの監視ツールのこと。EC2のCPU使用率、メモリ使用率、死活監視、ドキュメントルートのURL監視は最低限入れます。
メモリとCPUについては2段階(70%&90)でアラートを設定することが多いように思います。

おわりに

WordPressの管理画面経由でファイルをアップロードしようとすると、本構成ではファイルがALBによって分散されてしまうため、S3を立てるもしくは、rsyncを利用したしサーバ間でファイルの同期設定が必要です。
rsyncについては別で記事を書いたのでご参考になれば幸いです。
EC2×2台S3なし環境にて、/wp-content/uploadsディレクトリの内容を一方向同期する
 EC2×2台S3なし環境にて、WordPressの管理画面アクセスを片方のサーバに集中させる