【要約】2026年今から WordPress を立ち上げるなら — AWS Lightsail + Cloudflare WAF を使った構築手順 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
WordPressサイトの運営者は、公開直後から脆弱性を突いた攻撃に晒されるリスクに直面している。特に、対策の遅れやプラグインへの過度な依存は、以下の問題を引き起こす。
- ・脆弱性公開から悪用までの時間が極めて短い（中央値5時間）。
- ・セキュリティプラグインがPHP層で動作するため、攻撃時にサーバーリソースを消費し、正規ユーザーのレスポンスを低下させる。
- ・サーバーの実IPアドレスが露出していると、WAFを迂回して直接攻撃を受ける。
// Approach
攻撃をサーバーに到達させる前にエッジで遮断する「WAF前提の構成」を採用している。CloudflareをDNSプロキシとして配置し、以下のステップで構築を進める。
- ・Lightsailに静的IPを割り当て、SSHアクセスを特定のIPに制限する。
- ・LightsailのファイアウォールをCloudflareのIPレンジのみに制限し、直接アクセスを遮断する。
- ・certbotを用いてSSL証明書を取得した後、Cloudflareのプロキシを有効化し「フル（厳格）」モードに設定する。
- ・Cloudflare WAFのカスタムルールを用い、ログイン画面やXML-RPCへのアクセスを制限・ブロックする。
// Result
月額5ドル程度の低コストで、高い防御力を備えたWordPress環境を実現できる。
- ・Cloudflareのエッジで攻撃を止めるため、サーバーのリソースを正規ユーザーの処理に集中できる。
- ・実IPの隠蔽とファイアウォールの制限により、WAFを迂回する直接攻撃を防止できる。
- ・セキュリティプラグインの負荷を抑えつつ、ファイル改ざん検知などの補完的な運用が可能になる。
Senior Engineer Insight
> 低コストなLightsailを使いつつ、エッジでの防御を徹底する設計思想は非常に合理的だ。特に、プラグインの限界を指摘し、Cloudflare WAFを主軸に据える判断は、リソース活用として高く評価できる。ただし、IPレンジ変更への追従や、SSL取得の順序といった作法が、可用性に直結する点には注意が必要だ。