Astroブログの公開経路をVPS直公開からAWS前段構成へ切り替えました

ドメイン変わりました

旧ドメイン: blog.izuki-nana.net

↓

新ドメイン: blog.izu-san.com

今後ともよろしくお願い致します。

はじめに

これまでこのブログは、VPS3 上の Nginx からそのまま公開していました。
この構成でも普通に動いてはいたのですが、公開経路の保護やバックアップ、監視まわりをもう少しちゃんとしたくなってきたので、AWS を前段に足していく形にしました。

完全に VPS を捨てて S3 静的ホスティングへ移した、という話ではありません。
今回は VPS3 をオリジンとして残しつつ、CloudFront + WAF + Route 53 を前段に追加し、S3 をバックアップ先として使い始めた というのが実態です。

移行前の構成

以前の記事「趣味ブログの構成メモ」の時点では、ざっくり次のような形でした。

VPS1: Redmine + GitLab Runner
VPS2: GitLab 本体
VPS3: Astro ブログ配信先（Nginx）
GitLab CI から VPS3 へ rsync でデプロイ

要するに、ブログの公開そのものは VPS3 にかなり寄っていました。
シンプルで分かりやすい一方、WAF、外部監視、バックアップの整理はまだこれから、という状態でした。

今回追加したAWS構成

今回追加した主な要素は次の4つです。

CloudFront: blog.izu-san.com の前段に置くCDN
AWS WAF: CloudFront に関連付ける Web ACL
Route 53: CloudFront への Alias 切替とヘルスチェック管理
S3: VPS1 / VPS2 / VPS3 のバックアップ保存先b

ざっくりと構成としては次のイメージです。

AWS Images

VPS3 自体は引き続き配信オリジンとして使い、公開面だけ AWS 側に寄せた形です。
いきなり全部を載せ替えるより、この段階的な移行のほうが個人運用ではかなり気楽でした。

CloudFront + WAF を前段に置いた

CloudFront のオリジンは S3 ではなく VPS3

今回いちばん大きい変更はここです。
CloudFront の Origin には S3 バケットではなく、VPS3 側に用意した オリジン用サブドメイン を設定しました。

公開URL: blog.izu-san.com
オリジンURL: オリジン用サブドメイン
Viewer Protocol Policy: Redirect HTTP to HTTPS
Cache Policy: CachingOptimized
TLS: TLSv1.2_2021

Astro は静的サイトなので S3 配信に全振りする案もあったのですが、今回は既存の VPS3 運用を活かしつつ、まずは公開経路だけ AWS 化する方針にしました。
このほうが切り戻しも簡単で、事故っても VPS 直向けに戻しやすいです。

WAF を CloudFront に関連付け

Web ACL には、とりあえず次のルールを入れました。

AWSManagedRulesAmazonIpReputationList は Block
AWSManagedRulesCommonRuleSet は最初は Count
AWSManagedRulesKnownBadInputsRuleSet も最初は Count
Rate-based rule は 1IP あたり 2000

最初から全部 Block にすると誤検知がちょっと怖いので、まずは Count で様子を見る形です。
個人ブログでも、こういう「いきなり強くしすぎない」運用のほうが現実的だと思っています。

オリジン直アクセスも塞いだ

CloudFront を前に置くだけだと、VPS3 のオリジンへ直接来られると意味が薄いです。
そのため Nginx 側では X-Origin-Verify ヘッダをチェックし、一致しない場合は 403 を返すようにしました。

これで、

通常の閲覧者は blog.izu-san.com -> CloudFront 経由でアクセス
オリジン用サブドメイン へのヘッダ無し直アクセスは拒否

という形になっています。
このへんは「CDN を置いて終わり」にしないための最低限の防御という感じです。

Route 53 で切替と監視をまとめた

本番切替は Alias で実施

Route 53 では blog.izu-san.com の A / AAAA レコードを CloudFront Distribution への Alias に切り替えました。
CloudFront 側の証明書は us-east-1 の ACM で発行しており、このあたりは AWS のお作法そのままですね。

また、CloudFront のオリジン用に オリジン用サブドメイン も Route 53 側で管理しています。

ついでに外形監視も Route 53 に寄せた

AWS を使い始めたついでに、Route 53 Health Check も入れました。

blog.izu-san.com
gitlab.izu-san.com
redmine.izu-san.com

この3つを HTTPS で監視して、CloudWatch Alarm と SNS 通知につなぐ構成です。
ブログだけでなく、周辺の運用系も少しずつ AWS 側へ寄せている感じです。

S3 は配信先ではなくバックアップ先として使い始めた

今回の S3 の役割は、静的サイトのホスティングではなく バックアップ保管先 です。

バックアップ用バケットはバージョニングを有効化し、backup/ 配下に VPS ごとのプレフィックスを分けています。

backup/vps1/*
backup/vps2/*
backup/vps3/*

しかも、各 VPS から直接 S3 の長期キーを持たせるのではなく、sts assume-role で短期クレデンシャルを取得してアップロードする形にしました。
このへんはちょっと面倒でしたが、長期キーをそのまま置きっぱなしにするよりはかなり安心です。

やってみてよかった点

1. 公開経路がかなり整理された

今までは「VPS3 がそのまま表に出ている」感が強かったのですが、CloudFront と WAF を前段に置いたことで公開レイヤがかなり整理されました。
特に WAF を挟んだうえで origin 直アクセスも塞げたのは、見た目以上に安心感があります。

2. 切り戻ししやすい

今回は VPS3 自体を消したわけではないので、問題があれば Route 53 を戻して VPS 直向けに切り替える、というロールバックができます。
個人運用だと、この「最悪戻せる」が本当に大事です。

3. AWSの運用知識がちゃんと増える

CloudFront, WAF, ACM, Route 53, S3, CloudWatch, SNS あたりが一気につながるので、触っていてかなり勉強になります。
趣味ブログを使ってインフラの練習をするのは、やっぱりちょうどいいですね。

苦労した点

オリジン保護は CloudFront 側と Nginx 側の両方を見る必要がある

CloudFront にカスタムヘッダを入れるだけでは終わらず、Nginx 側でもその値をちゃんと検証しないといけません。
片方だけ直して満足すると普通に穴が残るので、ここは少し神経を使いました。

監視と予算アラートまで含めると意外とやることが多い

CloudFront と WAF を置くだけならまだしも、Route 53 Health Check、証明書期限監視、Budgets までやろうとすると一気に「AWS運用してる感」が出てきます。
便利ではあるのですが、個人ブログとしてはちょっとずつ増やすくらいがちょうどよさそうです。

1ヶ月様子を見てみて課金額がいくらくらいになるのか気になりますね。

まとめ

今回は、Astro ブログを VPS 直公開から完全に AWS へ載せ替えたのではなく、VPS3 を残したまま CloudFront + WAF + Route 53 を前段に追加し、S3 バックアップと監視基盤を整え始めた という移行でした。
まだまだAWSは勉強中なので、できそうなことがあれば色々やってみたいですね。