WordPressをAWS上に構築する

タイトルにあるWordPressは自分がIT業界に入った直後に多く関わったものであり、いくらか思いを感じるものがあり、継続的にアンテナを張ってはいたものでした。

ただ、最近はあまり関わることがなくなっていたので年末年始のまとまった時間に良い復習になると思ったので作りました。このブログです。

その際の感想などをメモします。

今回はとにかくシンプルにハードル低くやることを優先した作りでやってみました。

VPC作成が便利になっていた

最近は、IaCの重要度が増していて、仕事においてはAWSのマネジメントコンソール上で画面をポチポチと操作しながらリソースを準備することはなくなってきているのですが、初心に帰ってマネジメントコンソール上で操作してみました。

（プライベートだと、IaCでインフラをバリバリ作る体制があるわけではないので環境構築自体もめんどうということもあり。）

マネジメントコンソール使ってすごく体感したのですが、AWSでのアップデートでVPC作成のウィザードが便利になっていて、かなり楽にVPCを作成できるようになっていました。

VPCだけじゃなくて、その中のAZ、パブリック/プライベートサブネットの数なども指定して生成してくれるのが嬉しいですね。

これで、複数のAZにまたがった形で、冗長性を確保したネットワークを作成できました。

EC2はAmazon Linux2023

OSはAWSを使っている上では、無難にAmazon Linux2023かなと。

キーペアの管理もめんどくさいので、SSHポートは閉じて、サーバー内作業はセッションマネージャーで行うことにしました。

Amazon Linux2023であれば、セッションマネージャー用のエージェントインストールも気にしなくて良いので楽です。

SSM接続用のインスタンスプロファイルの作成もめんどくさいのでSystem ManagerのQuick Setupを使って、SSM接続用のインスタンスプロファイルを作成しました。

Quick Setupの画面見ると、今回のインスタンスプロファイルの設定以外にも、マネジメントコンソールで、ささっとやる時には便利そうなセットが結構並んでいるんですね。

ターゲット指定も、ささっと「すべてのインスタンス」を対象。

今回はやりませんでしたが、タグやリソースグループで精緻に指定できるようで、業務ユースで考えた時にIaCとの棲み分けに迷いそう。（便利なものが増えてうれしい悲鳴だろうけど）

DBはRDS（MySQL）

データベースは、MySQLのRDSを選択。

Aurora Serverlessで、「必要な時だけスケールしてコストを下げる」みたいなことも考えたのですが、WordPressはその性質上常時稼働を求められるので、今回は断念。（シンプルに早いところインフラを立ち上げたかったのもあるし）

DNSはRoute53

https化するための証明書の取得とその後のドメイン検証（※）のための設定が便利になるので、ドメインのホストゾーンはRoute53にて構築。（単純にAWS内で完結させた方が楽なことは多いですし）

ドメイン自体はお名前.comで取得していたので、お名前.comの管理画面でネームサーバーをRoute53のものに変更する形。

やったあとに気がついたのですが、せっかくの良い機会だったので、Route53上からのドメイン取得もやってみればよかったなとちょっと後悔。

※：https://docs.aws.amazon.com/jajp/acm/latest/userguide/dns-validation.html#setting-up-dns-validation

WAFをつけた

「どうせ立ち上げ直後の誰も見ていないサイトだし」と思っていたのですが、WordPressの立ち上げ直後からアクセスログをtailしていると、結構早い段階からbotの類のアクセスが見受けられたのが驚きでした。

アクセスしてきているPathを見ると、検索エンジンのクローラーもあるのですが、管理画面を狙った攻撃と思しきものもありました。

とはいえ、立ち上げ直後にがっつりWAFのソリューションにお金かけるのも現実的ではない気がしたので、AWSが提供しているManaged Ruleを使って最低限のWAFの仕組みを設定しました。

追加料金なしで使えるManaged Ruleが結構あって、WordPressのユースケースに合いそうなものが結構あって嬉しいですね。

料金的にはWebACL自体に月額料金がかかるのと、追加料金がなくともRuleをひとつ入れること自体にも料金がかかるので、しばらく動かしつつ、効率的にBlockをしてくれているルールに減らしていくのが良さそうかな。

アーキテクチャ

アーキテクチャ図としてはこんな感じですかね。

Security Groupは、EC2,ALB,RDSのようにそれぞれにリソースに対して紐づくように指定して、通信経路が精緻に制御されるようにしてあります。

まとめ

久しぶりにゼロからマネジメントコンソールを使って、インフラ作成したのですが、

VPC作成のウィザードがとにかく便利ですね。リソース名もよしなに規則性を持ったネーミングで作成してくれますし。

Terraformだと、”Registry”にあるModule（※）を使って、最低限のパラメーター渡すだけで必要なリソースを作成してくれる仕組みがありますが、Driftが起きた時のトラブルシュートが辛かった思い出が。。。

※：https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest

やはり、運用面を考えるとIaC化されていた方が良いのですが、IaCとマネジメントコンソールの使い分けがまた難しくなりましたね。（これもまた、例によって便利なものが増えてうれしい悲鳴ですが）

冒頭に書いたようにウィザードに沿ってVPC・サブネットを作成したので、実際にはAZは2つになっていたりと端折っている部分はあるのですが、今回は割愛。

WordPressのインストール作業自体も結構面倒でありつつ、wp-cliを使って助かったところもあったので、その辺りはまた別の記事で書こうかなと思います。

では。